search for: ref4

...necessary (Eric?). I haven't given it a great deal of thought. >>> >> >> >> Patches are reattached for convenience: remove DIE duplication with a >> worklist (name it patch_with), remove DIE duplication without a worklist >> but an assertion when we emit a ref4, we make sure the DIE and the >> referenced DIE belong to the same CU (name it patch_without). >> > > OK, we're going round in circles here and I'm not sure there are many > other ways I can communicate things. > > >> Without my patch, the assumption may be...

...violate it - but I'm not sure that's > necessary (Eric?). I haven't given it a great deal of thought. > Patches are reattached for convenience: remove DIE duplication with a worklist (name it patch_with), remove DIE duplication without a worklist but an assertion when we emit a ref4, we make sure the DIE and the referenced DIE belong to the same CU (name it patch_without). Without my patch, the assumption may be true, but it does not matter since we should always use ref4. I have provided some cases that the assertion fails with patch_without. I didn't get a chance to im...

...ure that's >> necessary (Eric?). I haven't given it a great deal of thought. >> > > > Patches are reattached for convenience: remove DIE duplication with a > worklist (name it patch_with), remove DIE duplication without a worklist > but an assertion when we emit a ref4, we make sure the DIE and the > referenced DIE belong to the same CU (name it patch_without). > OK, we're going round in circles here and I'm not sure there are many other ways I can communicate things. > Without my patch, the assumption may be true, but it does not matter since...

...t;>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Why does addDIEEntry take a form? When does the caller get to >>>>>>>>>> choose the form rather than the callee deciding between ref4 and ref_addr >>>>>>>>>> based on context? >>>>>>>>>> >>>>>>>>> >>>>>>>>> addDIEEntry took a form before my change and I didn't check why it >>>>>>>>> did....

...;> Done in attached patch. >>>>>> >>>>>>> >>>>>>> >>>>>>>> Why does addDIEEntry take a form? When does the caller get to >>>>>>>> choose the form rather than the callee deciding between ref4 and ref_addr >>>>>>>> based on context? >>>>>>>> >>>>>>> >>>>>>> addDIEEntry took a form before my change and I didn't check why it >>>>>>> did. >>>>>>> I will che...

...> >>>>> Done in attached patch. >>>>> >>>>>> >>>>>> >>>>>>> Why does addDIEEntry take a form? When does the caller get to >>>>>>> choose the form rather than the callee deciding between ref4 and ref_addr >>>>>>> based on context? >>>>>>> >>>>>> >>>>>> addDIEEntry took a form before my change and I didn't check why it >>>>>> did. >>>>>> I will check if all callers always...

...Debug level. When building the CU for src2.cpp we create the 'foo::bar<baz>' DIE, in doing so, we must construct a DIE for 'baz' and while doing that we come back around to find 'foo::bar<baz>' without a parent, assume it's in the current CU(src2.cpp) and use ref4. Then we finish building 'foo::bar<baz>' and add it to 'foo' which is in the src1.cpp CU. Broken. Eric and I chatted through some of these scenarios and we seem to think there's a different solution - rather than using a worklist, what we should've done was add 'f...

...leUnit. >>>>> >>>> Done in attached patch. >>>> >>>>> >>>>> >>>>>> Why does addDIEEntry take a form? When does the caller get to >>>>>> choose the form rather than the callee deciding between ref4 and ref_addr >>>>>> based on context? >>>>>> >>>>> >>>>> addDIEEntry took a form before my change and I didn't check why it did. >>>>> I will check if all callers always use ref4, if it it true, I will >>>...

...t;> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Why does addDIEEntry take a form? When does the caller get to >>>>>>>>>>> choose the form rather than the callee deciding between ref4 and ref_addr >>>>>>>>>>> based on context? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> addDIEEntry took a form before my change and I didn't check why >>>>>>>...

...ed patch. >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Why does addDIEEntry take a form? When does the caller get to >>>>>>>>> choose the form rather than the callee deciding between ref4 and ref_addr >>>>>>>>> based on context? >>>>>>>>> >>>>>>>> >>>>>>>> addDIEEntry took a form before my change and I didn't check why it >>>>>>>> did. >>>>&gt...

The first patch seems fine, though the comment on the modified addDIEEntry function is a bit confusing: -/// addDIEEntry - Add a DIE attribute data and value. +/// addDIEEntry - Add a DIE attribute data and value. The form should be +/// a reference form: ref1, ref2, ref4, ref8, ref_udata, ref_addr, +/// or ref_sig8. A form can be chosen inside addDIEEntry. When the comment says "The form should be" - it sounds like it /could/ be something else, etc. As though the caller would specify it and must meet some requirement. But the caller doesn't specify i...

...gt;>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Why does addDIEEntry take a form? When does the caller get >>>>>>>>>>>> to choose the form rather than the callee deciding between ref4 and >>>>>>>>>>>> ref_addr based on context? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> addDIEEntry took a form before my change and I didn't check why >>>...

...gt;>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Why does addDIEEntry take a form? When does the caller get >>>>>>>>>>>>> to choose the form rather than the callee deciding between ref4 and >>>>>>>>>>>>> ref_addr based on context? >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> addDIEEntry took a form before my change and I didn't check...

...ad >>>> of CompileUnit. >>>> >>> Done in attached patch. >>> >>>> >>>> >>>>> Why does addDIEEntry take a form? When does the caller get to >>>>> choose the form rather than the callee deciding between ref4 and ref_addr >>>>> based on context? >>>>> >>>> >>>> addDIEEntry took a form before my change and I didn't check why it did. >>>> I will check if all callers always use ref4, if it it true, I will >>>> submit a cleanu...

...y the map is in DwarfDebug instead >>> of CompileUnit. >>> >> Done in attached patch. >> >>> >>> >>>> Why does addDIEEntry take a form? When does the caller get to choose >>>> the form rather than the callee deciding between ref4 and ref_addr based on >>>> context? >>>> >>> >>> addDIEEntry took a form before my change and I didn't check why it did. >>> I will check if all callers always use ref4, if it it true, I will >>> submit a cleanup patch first. >>&...

...> >>>>> Done in attached patch. >>>>> >>>>>> >>>>>> >>>>>>> Why does addDIEEntry take a form? When does the caller get to >>>>>>> choose the form rather than the callee deciding between ref4 and ref_addr >>>>>>> based on context? >>>>>>> >>>>>> >>>>>> addDIEEntry took a form before my change and I didn't check why it >>>>>> did. >>>>>> I will check if all callers always...

...one in attached patch. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Why does addDIEEntry take a form? When does the caller get to >>>>>>>> choose the form rather than the callee deciding between ref4 and ref_addr >>>>>>>> based on context? >>>>>>> >>>>>>> >>>>>>> addDIEEntry took a form before my change and I didn't check why it >>>>>>> did. >>>>>>> I will check i...

...nd insertDIE. I like > isSharableAcrossCUs, because that is why the map is in DwarfDebug instead > of CompileUnit. > Done in attached patch. > > >> Why does addDIEEntry take a form? When does the caller get to choose >> the form rather than the callee deciding between ref4 and ref_addr based on >> context? >> > > addDIEEntry took a form before my change and I didn't check why it did. > I will check if all callers always use ref4, if it it true, I will submit > a cleanup patch first. > Done in attached patch. > > I'm still u...

...e context for a member function and attach the member function to that context before we build any of its parameters, template arguments, etc. > > >> >> >>> When Die or CU does not have an owner, what assumption should we make >>> to decide between ref_addr and ref4 inside addDIEEntry? >>> >> >> The claim Eric and I are making/discussed is that we should assume any >> DIE without a parent is in the current CU and/or that it possibly should >> never come up (I haven't thought through the codepaths carefully here - if >&gt...

...bleAcrossCUs, because that is why the map is in DwarfDebug instead >> of CompileUnit. >> > Done in attached patch. > >> >> >>> Why does addDIEEntry take a form? When does the caller get to choose >>> the form rather than the callee deciding between ref4 and ref_addr based on >>> context? >>> >> >> addDIEEntry took a form before my change and I didn't check why it did. >> I will check if all callers always use ref4, if it it true, I will submit >> a cleanup patch first. >> > Done in attached pa...