search for: inlined_subroutine

...at 1:21 PM, Manman Ren <manman.ren at gmail.com> wrote: > > There are a few places where we break the assumption: > 1> 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 b...

...lt;manman.ren at gmail.com> wrote: > >> >> There are a few places where we break the assumption: >> 1> 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&...

There are a few places where we break the assumption: 1> 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",...

...t; >>>> >>>> There are a few places where we break the assumption: >>>> 1> 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 >>>> b...

...om> wrote: >> >>> >>> There are a few places where we break the assumption: >>> 1> 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 a...

...rp is the same size as DW_FORM_ref4 (though DW_FORM_strp would >> mean extra relocations...) - and perhaps in the near future, DW_FORM_strp >> could be replaced by DW_FORM_str_index to reduce relocations) >> > > Yes, this might work. Generally, when we find a > subprogram/inlined_subroutine DIE we calculate its name by following the > DW_AT_specification/DW_AT_abstract_origin links until we find a DIE with > DW_AT_name provided. If we're able to get the name directly things will > only be better. > So long as you look for the name on the inlined_subroutine first, befo...

Aha, okay. I had noticed that the column-info hack went away. So the distinct-ness implies the scope implicit in the inlined call, which later on will be turned into the explicit inlined_subroutine entry. That seems… indirect. I have to say, the LangRef page's words about "merge based on content" is not really to the point. It's like saying the purpose of a street-corner STOP sign is to make you stop. That's the mechanism it uses, but it's not why the sign is the...

In an effort to fix inlined information for backtraces under DWARF Fission in the absence of the split DWARF (.dwo) files, I'm planning on adding -gmlt-like data to the .o file, alongside the skeleton CU. Since that will involve teaching the LLVM about -gmlt (moreso than it already has - the debug info LLVM metadata already describes -gmlt for the purposes of omitting pubnames in that case) I

I'm encountering a merge issue whose root cause has to do with "distinct" metadata nodes. I see that distinct-ness is an intentional concept, but the explanation in the LLVM Language Reference is not very enlightening. distinct nodes are useful when nodes shouldn't be merged based on their content. The notion of "merged" metadata is not discussed elsewhere on

On Wed, Oct 16, 2013 at 11:10 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Wed, Oct 16, 2013 at 10:54 AM, Manman Ren <manman.ren at gmail.com> wrote: > >> >> >> >> On Tue, Oct 15, 2013 at 5:59 PM, David Blaikie <dblaikie at gmail.com>wrote: >> >>> >>> In beginModule, we construct the CUs, but not all

17.09.2019 3:12, David Blaikie пишет: > > > On Wed, Sep 11, 2019 at 3:32 PM Alexey Lapshin via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Debuginfo and linker folks, we (AccessSoftek) would like to > suggest a proposal for removing obsolete debug info. If you find > it useful we will be happy to work on

...(cu + 0x0056 => > {0x00000056} "_Z2f1v") >         DW_TAG_subprogram >           DW_AT_name "f1" > 0x6e: DW_TAG_compile_unit >         DW_AT_name "b.cpp" > 0x8d:   DW_TAG_subprogram >           DW_AT_name "main" > 0xa6:     DW_TAG_inlined_subroutine >             DW_AT_abstract_origin [DW_FORM_ref_addr] > (0x0000000000000056 "_Z2f1v") > > ueaueoa > ueaoueoa > > Notice that the inlined_subroutine's abstract_origin uses a linker > relocation into the debug_info section to give an absolute offset > with...

On Wed, Oct 16, 2013 at 10:54 AM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Tue, Oct 15, 2013 at 5:59 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> >> 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

...file (c.dwo, ab.dwo). If we look at the contents, they make a fair bit of sense: 0x0b: DW_TAG_compile_unit [1] * 0x19: DW_TAG_subprogram [2] 0x25: DW_TAG_subprogram [3] 0x31: DW_TAG_subprogram [4] 0x43: DW_TAG_compile_unit [1] * 0x51: DW_TAG_subprogram [5] * 0x5d: DW_TAG_inlined_subroutine [6] DW_AT_abstract_origin [DW_FORM_ref_addr] (0x31 "_Z2f2v") The ref_addr can be resolved relative to this whole .dwo file & the abstract subprogram is found. Yay. So GDB can't currently handle this: Could not find DWO CU ab.dwo(0x32dd6d7121dd1d9a) referenc...