search for: inlined_subroutine

Displaying 14 results from an estimated 14 matches for "inlined_subroutine".

2013 Oct 16
0
[LLVMdev] [Debug Info PATCH] for support of ref_addr and removal of DIE duplication
...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...
2013 Oct 17
2
[LLVMdev] [Debug Info PATCH] for support of ref_addr and removal of DIE duplication
...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&...
2013 Oct 16
2
[LLVMdev] [Debug Info PATCH] for support of ref_addr and removal of DIE duplication
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",...
2013 Oct 17
1
[LLVMdev] [Debug Info PATCH] for support of ref_addr and removal of DIE duplication
...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...
2013 Oct 17
0
[LLVMdev] [Debug Info PATCH] for support of ref_addr and removal of DIE duplication
...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...
2014 Aug 28
2
[LLVMdev] Minimizing -gmlt
...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...
2015 Apr 06
2
[LLVMdev] "distinct" metadata nodes are ...?
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...
2014 Aug 27
6
[LLVMdev] Minimizing -gmlt
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
2015 Apr 06
2
[LLVMdev] "distinct" metadata nodes are ...?
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
2013 Oct 16
0
[LLVMdev] [Debug Info PATCH] for support of ref_addr and removal of DIE duplication
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
2019 Sep 18
2
Remove obsolete debug info while garbage collecting
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
2019 Sep 20
3
Remove obsolete debug info while garbage collecting
...(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...
2013 Oct 16
3
[LLVMdev] [Debug Info PATCH] for support of ref_addr and removal of DIE duplication
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
2017 May 03
3
DWARF Fission + ThinLTO
...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...