search for: adddieentry

> In beginModule, we construct the CUs, but not all the DIEs that belong to >>> the CU. >>> In endFunction, we started to construct the scope DIEs. So in some >>> sense, we are adding things to prior CUs. >>> >>> Looking at void CompileUnit::addDIEEntry(DIE *Die, uint16_t Attribute, >>> DIE *Entry), we can possibly have 3 CUs, this CU, >>> the CU Die belongs to (i.e. the CU the parent chain points to), the CU >>> Entry belongs to. >>> >> >> When does "this CU" differ from both the Die and t...

...t;>>>>> >>>>>>>>>>> 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? >>>>>>>>>>>>> >&gt...

...t; formal_parameter constructed in DwarfDebug when adding attribute type we call SPCU->addType(Arg, ATy), where Arg does not belong to SPCU. 2> inlined_subroutine constructed in DwarfDebug when adding attribute abstract_origin The inlined_subroutine does not belong to the CU we call addDIEEntry on. We create the children of inlined_subroutine and call addDIEEntry before we add it to an owner. 3> ... When building xalan with "lto -g", I saw 3158 violations of the assumption. Should we try to fix all these violations to make the assumption true? As I stated earlier, this...

...> we call SPCU->addType(Arg, ATy), where Arg does not belong to SPCU. >>>> 2> inlined_subroutine constructed in DwarfDebug when adding attribute >>>> abstract_origin >>>> The inlined_subroutine does not belong to the CU we call >>>> addDIEEntry on. >>>> We create the children of inlined_subroutine and call addDIEEntry >>>> before we add it to an owner. >>>> 3> ... >>>> >>>> When building xalan with "lto -g", I saw 3158 violations of the >>>> assumpti...

...uct the CUs, but not all the DIEs that belong >>>>> to the CU. >>>>> In endFunction, we started to construct the scope DIEs. So in some >>>>> sense, we are adding things to prior CUs. >>>>> >>>>> Looking at void CompileUnit::addDIEEntry(DIE *Die, uint16_t Attribute, >>>>> DIE *Entry), we can possibly have 3 CUs, this CU, >>>>> the CU Die belongs to (i.e. the CU the parent chain points to), the CU >>>>> Entry belongs to. >>>>> >>>> >>>> When does &q...

...t;>>>>>>>>>> >>>>>>>>>> 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? >>>>>>>>>>>> >>>>&gt...

...ginModule, we construct the CUs, but not all the DIEs that belong >>>> to the CU. >>>> In endFunction, we started to construct the scope DIEs. So in some >>>> sense, we are adding things to prior CUs. >>>> >>>> Looking at void CompileUnit::addDIEEntry(DIE *Die, uint16_t Attribute, >>>> DIE *Entry), we can possibly have 3 CUs, this CU, >>>> the CU Die belongs to (i.e. the CU the parent chain points to), the CU >>>> Entry belongs to. >>>> >>> >>> When does "this CU" differ...

...all the DIEs that >>>>>> belong to the CU. >>>>>> In endFunction, we started to construct the scope DIEs. So in some >>>>>> sense, we are adding things to prior CUs. >>>>>> >>>>>> Looking at void CompileUnit::addDIEEntry(DIE *Die, uint16_t >>>>>> Attribute, DIE *Entry), we can possibly have 3 CUs, this CU, >>>>>> the CU Die belongs to (i.e. the CU the parent chain points to), the >>>>>> CU Entry belongs to. >>>>>> >>>>> >>&...

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 com...

...warfDebug when adding attribute type >> we call SPCU->addType(Arg, ATy), where Arg does not belong to SPCU. >> 2> inlined_subroutine constructed in DwarfDebug when adding attribute >> abstract_origin >> The inlined_subroutine does not belong to the CU we call addDIEEntry >> on. >> We create the children of inlined_subroutine and call addDIEEntry >> before we add it to an owner. >> 3> ... >> >> When building xalan with "lto -g", I saw 3158 violations of the >> assumption. Should we try to fix all these viol...

...te type >>> we call SPCU->addType(Arg, ATy), where Arg does not belong to SPCU. >>> 2> inlined_subroutine constructed in DwarfDebug when adding attribute >>> abstract_origin >>> The inlined_subroutine does not belong to the CU we call >>> addDIEEntry on. >>> We create the children of inlined_subroutine and call addDIEEntry >>> before we add it to an owner. >>> 3> ... >>> >>> When building xalan with "lto -g", I saw 3158 violations of the >>> assumption. Should we try to fix...

...constructed in DwarfDebug when adding attribute type > we call SPCU->addType(Arg, ATy), where Arg does not belong to SPCU. > 2> inlined_subroutine constructed in DwarfDebug when adding attribute > abstract_origin > The inlined_subroutine does not belong to the CU we call addDIEEntry > on. > We create the children of inlined_subroutine and call addDIEEntry > before we add it to an owner. > 3> ... > > When building xalan with "lto -g", I saw 3158 violations of the > assumption. Should we try to fix all these violations to make the > assu...

...rtDIE are sure to use >> the same test at all times. >> > Yes, the condition is shared between getDIE and 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...

...gt;>>>>>> belong to the CU. >>>>>>> In endFunction, we started to construct the scope DIEs. So in some >>>>>>> sense, we are adding things to prior CUs. >>>>>>> >>>>>>> Looking at void CompileUnit::addDIEEntry(DIE *Die, uint16_t >>>>>>> Attribute, DIE *Entry), we can possibly have 3 CUs, this CU, >>>>>>> the CU Die belongs to (i.e. the CU the parent chain points to), the >>>>>>> CU Entry belongs to. >>>>>>> >>>&g...

...est at all times. >>> >> Yes, the condition is shared between getDIE and 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 call...

...;> 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? >>>>>>>>>>> >>>>>>>&gt...

...;>>>>>>> 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? >>>>>>>>>> >>>>>>>>> >&g...

...E. 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 di...

...t; 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 befor...

...use 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? >>>>>>>> >>>>>>> >>>>>>> addDIEEnt...