Re: [Dwarf-discuss] [DWARF5] .debug_names + fdebug-types-sections

> On Oct 16, 2023, at 9:12 AM, David Blaikie via Dwarf-discuss > wrote: > > > > On Mon, Oct 16, 2023 at 8:57 AM Alexander Yermolovich > wrote: >> For background llvm discussion on how to implement it: >> https://discourse.llvm.org/t/debuginfo-dwarfv5-lld-debug-name

Re: [Dwarf-discuss] Ranges for DW_TAG_namespace

When searching for addresses we first see if the compile unit's DW_AT_ranges (or low/high pc) attribute contains the address we are looking for. Any CU that doesn't contain the address doesn't need to have its child DIEs parsed, just the top level DW_TAG_compile_unit DIE. Then we iterate over al

Re: [Dwarf-Discuss] debug_aranges use and overhead

As long as there is a DW_AT_ranges on the CU the is complete, that is good enough for LLDB. No one seems to consistently emit .debug_aranges these days so we definitely don't rely on it. Greg > On Jun 14, 2022, at 1:10 PM, David Blaikie via Dwarf-Discuss > wrote: > > Given the discussion pre

Re: [Dwarf-Discuss] CU-local types

Template types are emitted for C++ in DWARF as specialized instances only, there is no generic definition of the type. One of the issues that impedes LLDB from functioning correctly in the expression parser for C++ with templates is how the accelerator table entries are emitted. If you have a "

Re: [Dwarf-Discuss] How to interpret DW_AT_artificial tag?

> On Feb 28, 2022, at 1:11 PM, David Blaikie via Dwarf-Discuss > wrote: > > > > On Mon, Feb 28, 2022 at 12:55 PM Greg Clayton via Dwarf-Discuss > mailto:dwarf-discuss@lists.dwarfstd.org>> > wrote: > > >> On Feb 28, 2022, at 5:49 AM, Ron Louzon

Re: [Dwarf-Discuss] How to interpret DW_AT_artificial tag?

> On Feb 28, 2022, at 5:49 AM, Ron Louzon via Dwarf-Discuss > wrote: > > I have an application which uses DwarfLib to extract type information from > debug executable images. I have found in the DWARF data that some structure > types have a "virtual" pointer added as their first member and

[Dwarf-Discuss] Producing .debug_names and questions about this lookup format

I am in the process if writing a tool that can add .debug_names to a file that contains DWARF but doesn’t have an accelerator table that is adequate for debuggers to use. I was trying to see some example implementations of the .debug_names section to see exactly what I should emit from this tool

Re: [Dwarf-Discuss] string reduction techniques

symbols that have mangled names that the DWARF refers to and cause the DW_FORM values to point to invalid offsets. > > On Tue, Nov 02, 2021 at 10:09:16AM -0700, Dwarf Discussion wrote: >> On Mon, Nov 1, 2021 at 7:14 PM Greg Clayton via Dwarf-Discuss >> <[1]dwarf-discuss@lists.

Re: [Dwarf-Discuss] string reduction techniques

LLDB also uses mangled names. The clang compiler is our expression parser and it always tries to resolve symbols during compilation/JIT and it supplies mangled names when looking for functions to resolve when it JITs code up. It is nice to be able to do quick name lookups using these mangled nam

Re: [Dwarf-Discuss] debug_aranges use and overhead

> On Mar 19, 2021, at 11:22 AM, Frank Ch. Eigler wrote: > > Hi - > >> We have seen GSYM files up to 20x smaller than the DWARF file, which >> to be fair often includes all other sections (.text, .data, etc). > > What information is lost? GSYM does not contain: - variable information (locals

Re: [Dwarf-Discuss] debug_aranges use and overhead

> On Mar 19, 2021, at 9:33 AM, Samy Al Bahra via Dwarf-Discuss > wrote: > > Hi David, > > Sorry I'm a bit late to the game. On the value of having .debug_aranges and > the performance impact: > > Our debugger was designed for performance and does end to end lazy evaluation > (down to the D

Re: [Dwarf-Discuss] debug_aranges use and overhead

> On Mar 11, 2021, at 1:12 PM, Paul Robinson via Dwarf-Discuss > wrote: > > Tom Russell could perhaps speak to this better, but my understanding is that > our debugger guys like having .debug_aranges, because parsing the CU DIE does > take that extra effort. I am unfamiliar with their code

Re: [Dwarf-Discuss] Retrieving variables, function address using dwarf

Most local variables have locations that do require registers. DW_OP_call_frame_cfa says it needs to push the value that defines the call frame address which is typically based on the SP or FP depending on how things were compiled, so you would need registers for this. DW_OP_fbreg is another co

Re: [Dwarf-Discuss] implicit_value vs stack_value

DW_OP_implicit_value, as you said, allows encoding a constant that can be larger than the stack value size, so it will always be needed for these kinds of constant values. > On Jan 4, 2021, at 11:30 AM, Paul Robinson via Dwarf-Discuss > wrote: > > Happy New Year, everybody! > > A colleague

Re: [Dwarf-Discuss] .debug_addr entry plus offset

One simple approach would be to be able to represent a DW_AT_low_pc with a DW_FORM_data encoding just like the DW_AT_high_pc does when it is an offset from the DW_AT_low_pc. The value of the DW_AT_low_pc would be an offset from either: 1 - the parent DIE's DW_AT_low_pc (which itself might need t

Re: [Dwarf-Discuss] .debug_addr entry plus offset

One simple approach would be to be able to represent a DW_AT_low_pc with a DW_FORM_data encoding just like the DW_AT_high_pc does when it is an offset from the DW_AT_low_pc. The value of the DW_AT_low_pc would be an offset from either: 1 - the parent DIE's DW_AT_low_pc (which itself might need t

Re: [Dwarf-Discuss] Stack tracing and return addresses off by 1

You are correct. For the first frame you don't adjust the PC when looking up the unwind row. For the second frame on up you can decrement the PC value by 1 before when doing the row lookup and that is usually enough to get you to the correct unwind row. The issue is that the return address point

Re: [Dwarf-Discuss] Question about DW_TAG_inlined_subroutine tags

> On Jul 30, 2020, at 12:21 PM, David Blaikie wrote: > > On Thu, Jul 30, 2020 at 12:00 PM Greg Clayton via Dwarf-Discuss > wrote: >> >> The LTO in clang creates some really interesting DWARF... One of the latest >> things I discovered is DW_TAG_inline

[Dwarf-Discuss] Question about DW_TAG_inlined_subroutine tags

The LTO in clang creates some really interesting DWARF... One of the latest things I discovered is DW_TAG_inlined_subroutine tags that are not contained within a DW_TAG_subprogram. I am guessing the compiler/linker wanted to outline an inlined function and tried its best to move the DWARF and di

Re: [Dwarf-Discuss] Selectively strip CUs from .debug_info?

Not aware of any tools that can do this, but can't you just do this in your build?: - link once with full .o files and save debug info off - strip debug info from all third party .o files and link again. You still get all debug info for any .o files you didn't strip > On Apr 9, 2020, at 2:50

Re: [Dwarf-Discuss] variable locations - safe use as lvalues

> On Jan 21, 2020, at 2:58 PM, Frank Ch. Eigler via Dwarf-Discuss > wrote: > > Hi - > >> While dwarfdump has 'check the DWARF' options available the >> location list overlap test is not done at all. The -kl option suggests >> it does loclist checking, but its checking is rather superficial.

Re: [Dwarf-Discuss] variable locations - safe use as lvalues

> On Jan 20, 2020, at 6:21 PM, Frank Ch. Eigler via Dwarf-Discuss > wrote: > > Hi - > >>> - ... and undoubtedly other complications exist! >> >> Interesting question. > > Thanks! > > We have been thinking in similar directions generally as y'all. > > >> Complication 2: The compiler reuse

Re: [Dwarf-Discuss] .debug_frame and the base address

> On Sep 24, 2018, at 8:44 AM, Robert Harris wrote: > > > >> On 24 Sep 2018, at 15:33, Greg Clayton wrote: >> >> >> >>> On Sep 24, 2018, at 7:15 AM, Robert Harris via Dwarf-Discuss >>> wrote: >>> >>> I'd like some clarification regarding what precisely needs to be relocated >>> relati

Re: [Dwarf-Discuss] .debug_frame and the base address

> On Sep 24, 2018, at 7:15 AM, Robert Harris via Dwarf-Discuss > wrote: > > I'd like some clarification regarding what precisely needs to be relocated > relative to > the object load address when interpreting .debug_frame. I'm interested in > versions > 2, 3 and 4. > > I think the only exp

Re: [Dwarf-Discuss] debug_names - what should go in ?

> On Apr 11, 2018, at 4:45 AM, Pavel Labath via Dwarf-Discuss > wrote: > > Thank you all for the feedback. There seems to be general consensus that > enumerators should be present in the name index. > > However, I am starting to have second thoughts about imported declarations. > While the