search for: dw_at_specification

...er friendly. There are quite a few features in Darwin’s dwarfdump that we find quite useful and that we would like to contribute to llvm-dwarfdump. I have started by augmenting the -debug-dump=info output: - Symbolic names for attribute values - Line table lookups for DW_AT_decl_file - Annotate DW_AT_specification with the target DIE’s name - DWARF expression pretty-printing With these enhancements, the debug_info dump is nearly always sufficient and the user rarely needs to go and decode himself the referenced content of other debug sections. There will be more work by me going on in llvm-dwarfdump/libDe...

...> 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, before walking DW_AT_specification/DW_AT_abstract_origin links, that'...

On 03.09.2020 01:36, David Blaikie wrote: > > > On Wed, Sep 2, 2020 at 3:26 PM Alexey <avl.lapshin at gmail.com > <mailto:avl.lapshin at gmail.com>> wrote: > > > On 02.09.2020 21:44, David Blaikie wrote: >> >> >> On Wed, Sep 2, 2020 at 9:56 AM Alexey <avl.lapshin at gmail.com >> <mailto:avl.lapshin at gmail.com>>

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

...aring dwarf info, it created a DIE 0x00000592 that was referred by another DIE 0x00000883 but somehow DIE 0x00000592 was not emitted. This could be a bug in DwarfDebug.cpp or how debug info is generated by FE. In DwarfDebug.cpp, you'll see code like addDIEEntry(VariableSpecDIE, dwarf::DW_AT_specification, dwarf::DW_FORM_ref4, VariableDIE); Here VariableSpecDIE is referring VariableDIE, but VariableDIE is missing from the output. There are other uses of DW_FORM_ref4 also. So check in our dwarfdump output what is 0x00000883 and set appropriate breakpoint in debugger and see why it is not reaching...

...s generic definitions... > > Right, DWARF today doesn't do that, although as I mentioned earlier > conjuring up a subroutine_type with template parameters would not > appear to be any more helpful than a simple flag on the class. Yeah, there would have to be new DWARF and a lot of DW_AT_specification or DW_AT_abstract_origin references involved... > >> >> Solution #3 will require compiler changes. > > Well, so does #2. Indeed. > >> So this is another vote to support the ability for a given class >> to be able to locate all of its functions, kind of lik...

...E 0x00000592 that was referred by another DIE 0x00000883 but > somehow DIE 0x00000592 was not emitted. This could be a bug in > DwarfDebug.cpp or how debug info is generated by FE. > > In DwarfDebug.cpp, you'll see code like > > addDIEEntry(VariableSpecDIE, > dwarf::DW_AT_specification, dwarf::DW_FORM_ref4, VariableDIE); > > Here VariableSpecDIE is referring VariableDIE, but VariableDIE is missing > from the output. There are other uses of DW_FORM_ref4 also. So check in our > dwarfdump output what is 0x00000883 and set appropriate breakpoint in > debugger and see...

I've been trying to track down the problem with the DWARF info that is being emitted by my front end, which has been broken for about a month now. Here's what happens when I attempt to use gdb to debug one of my programs on OS X: gdb stack crawl at point of internal error: [ 0 ] /usr/libexec/gdb/gdb-i386-apple-darwin (align_down+0x0) [0x122300] [ 1 ] /usr/libexec/gdb/gdb-i386-apple-darwin

...red by another DIE 0x00000883 but >> somehow DIE 0x00000592 was not emitted. This could be a bug in >> DwarfDebug.cpp or how debug info is generated by FE. >> >> In DwarfDebug.cpp, you'll see code like >> >> addDIEEntry(VariableSpecDIE, >> dwarf::DW_AT_specification, dwarf::DW_FORM_ref4, VariableDIE); >> >> Here VariableSpecDIE is referring VariableDIE, but VariableDIE is missing >> from the output. There are other uses of DW_FORM_ref4 also. So check in our >> dwarfdump output what is 0x00000883 and set appropriate breakpoint in >&...

...ve that role just fine) > > * we could just do a better job of modelling nested types (& other > non-globally scoped types) in a way that more closely models the source by > emitting a declaration where they were declared, and a definition where > they are defined (with the usual DW_AT_specification to wire them up) > > > *From:* David Blaikie [mailto:*dblaikie at gmail.com* <dblaikie at gmail.com>] > * Sent:* Wednesday, November 04, 2015 8:30 PM > * To:* *reviews+D14358+public+d3104135076f0a10 at reviews.llvm.org* > <reviews%2BD14358%2Bpublic%2Bd3104135076f0a10 at r...

...gt; The contents of the node have forward declaration versus definition. They won't be merged or RAUW'd. As you build up the hash table you can make sure that definitions win in creating DIEs yes? i.e. just add the full types to the map as you construct them and when you look up DW_AT_type/DW_AT_specification you can replace with the correct DIE? -eric > Thanks, > Manman > >> >> -eric >> >>> Thanks, >>> Manman >>> >>>> >>>> -eric >>>> >>>> >>>>> Thanks, >>>>> Manman >&...

...ve that role just fine) > > * we could just do a better job of modelling nested types (& other > non-globally scoped types) in a way that more closely models the source by > emitting a declaration where they were declared, and a definition where > they are defined (with the usual DW_AT_specification to wire them up) > > > *From:* David Blaikie [mailto:dblaikie at gmail.com] > * Sent:* Wednesday, November 04, 2015 8:30 PM > * To:* reviews+D14358+public+d3104135076f0a10 at reviews.llvm.org; Robinson, > Paul > * Subject:* Re: [PATCH] D14358: DWARF's forward decl of a temp...

...antry, just double checking) > Each function has its own fragment, which is in the same link-group > (COMDAT or whatever) as the function's .text section; that way, if the > function is discarded, so is the .debug_info fragment. Offhand I can't > think of any cases (other than DW_AT_specification, addressed below) of > references to a subprogram DIE from elsewhere, The call_site DWARF would want to refer to a subprogram DIE, but that could be handled by (first pass) having a declaration subprogram in the initial fragment that the call_site could refer to using the usual assembler-resolv...

...; Right, DWARF today doesn't do that, although as I mentioned earlier >>> conjuring up a subroutine_type with template parameters would not >>> appear to be any more helpful than a simple flag on the class. >> >> Yeah, there would have to be new DWARF and a lot of DW_AT_specification or >> DW_AT_abstract_origin references involved... >> >>> >>>> >>>> Solution #3 will require compiler changes. >>> >>> Well, so does #2. >> >> Indeed. >> >>> >>>> So this is another vote to...

On Wed, Jun 3, 2020 at 6:34 AM Robinson, Paul <paul.robinson at sony.com> wrote: > > DWARF was designed in an era when COMDAT and ICF were not a thing, or at least not common, certainly not when talking about function code. The overhead of a unit occurred only once per translation unit, so that expense was reasonably amortized. > > > > Splitting functions into their own

...E 0x00000592 that was referred by another DIE 0x00000883 but > somehow DIE 0x00000592 was not emitted. This could be a bug in > DwarfDebug.cpp or how debug info is generated by FE. > > In DwarfDebug.cpp, you'll see code like > > addDIEEntry(VariableSpecDIE, > dwarf::DW_AT_specification, dwarf::DW_FORM_ref4, VariableDIE); > > Here VariableSpecDIE is referring VariableDIE, but VariableDIE is missing > from the output. There are other uses of DW_FORM_ref4 also. So check in our > dwarfdump output what is 0x00000883 and set appropriate breakpoint in > debugger and see...

...ve that role just fine) > > * we could just do a better job of modelling nested types (& other > non-globally scoped types) in a way that more closely models the source by > emitting a declaration where they were declared, and a definition where > they are defined (with the usual DW_AT_specification to wire them up) > > > *From:* David Blaikie [mailto:dblaikie at gmail.com] > * Sent:* Wednesday, November 04, 2015 8:30 PM > * To:* reviews+D14358+public+d3104135076f0a10 at reviews.llvm.org; Robinson, > Paul > * Subject:* Re: [PATCH] D14358: DWARF's forward decl of a temp...

...> Each function has its own fragment, which is in the same link-group > > > (COMDAT or whatever) as the function's .text section; that way, if the > > > function is discarded, so is the .debug_info fragment. Offhand I can't > > > think of any cases (other than DW_AT_specification, addressed below) of > > > references to a subprogram DIE from elsewhere, > > > > The call_site DWARF would want to refer to a subprogram DIE, but that > > could be handled by (first pass) having a declaration subprogram in > > the initial fragment that the call_sit...

To elaborate a bit more on the issue that is detailed in https://reviews.llvm.org/rL260308: There are many clang AST contexts that are used in LLDB: - one for each lldb_private::Module that contains type definitions as we know them in the module and its symbol vendor - one for each expression - one for results of expressions in the lldb_private::Target As we run expressions we end up copying

...ve that role just fine) > > * we could just do a better job of modelling nested types (& other > non-globally scoped types) in a way that more closely models the source by > emitting a declaration where they were declared, and a definition where > they are defined (with the usual DW_AT_specification to wire them up) > > > *From:* David Blaikie [mailto:dblaikie at gmail.com] > * Sent:* Wednesday, November 04, 2015 8:30 PM > * To:* reviews+D14358+public+d3104135076f0a10 at reviews.llvm.org; Robinson, > Paul > * Subject:* Re: [PATCH] D14358: DWARF's forward decl of a temp...