[llvm-dev] llvm-dwarfdump on whole-split-file fails to account for indirection through skeleton

[David Blaikie via llvm-dev]

Yep, ended up fixing this myself in r345215 - turned out one of my test
cases was checking a bogus result already.

On Wed, Oct 24, 2018 at 1:15 PM David Blaikie <dblaikie at gmail.com> wrote:

> On Wed, Oct 24, 2018 at 1:11 PM <wolfgang.pieb at sony.com> wrote:
>
>> I don’t see anything in the DWARF 5 standard that would preclude multiple
>> skeletons in the same .o, but I think this is based on the assumption that
>> all the split units live in their respective .dwo files (or in a .dwp
>> file). I’m not sure how you could have several skeleton/split unit pairs in
>> a single .o in the non-split split DWARF scenario. For starters, there’s
>> supposed to be only one split unit per .debug_info.dwo section, so I don’t
>> know how several of them would even coexist in one object file (e.g. how
>> they would refer to their strings in the absence of a DW_str_offsets_base
>> attribute, the same goes for rangelists and location lists).
>>
>
> Yeah, that's a more accurate statement of the limitation - one split unit
> per .dwo, therefore one unit (well, one split and its matching skeleton)
> when using non-split Split DWARF in a single object file.
>
>
>>  I think it’s as Dave says:  We’ll have to restrict support for
>> non-split split DWARF to a single skeleton/split unit in a .o, which should
>> make lookup fairly straightforward.
>>
>
> *nod* turns out I have a need to fix this myself now anyway - so I'm
> working on that, might've come across a bug or two along the way, we'll see.
>
> But yeah, simple enough to just look for the only CU in the debug_info
> section for now. If we end up coming up with other scenarios to support we
> can cross that bridge when we come to it.
>
> - Dave
>
>
>>
>>
>> -- wolfgang
>>
>>
>>
>> *From:* Robinson, Paul
>> *Sent:* Wednesday, October 24, 2018 11:56 AM
>> *To:* David Blaikie; George Rimar; Pieb, Wolfgang
>> *Cc:* llvm-dev at lists.llvm.org
>> *Subject:* RE: [llvm-dev] llvm-dwarfdump on whole-split-file fails to
>> account for indirection through skeleton
>>
>>
>>
>> If we do find that multiple skeletons are possible in the same .o, we can
>> find the right one pretty cheaply by matching the dwo_id in the header.
>>
>> --paulr
>>
>>
>>
>> *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of *David
>> Blaikie via llvm-dev
>> *Sent:* Wednesday, October 24, 2018 2:34 PM
>> *To:* George Rimar; Pieb, Wolfgang; llvm-dev
>> *Subject:* [llvm-dev] llvm-dwarfdump on whole-split-file fails to
>> account for indirection through skeleton
>>
>>
>>
>> Hi folks,
>>
>> Just a minor bug I probably won't get to but thought I should raise:
>>
>> llvm-dwarfdump when run on an object file containing split-DWARF (so it
>> has both .debug_info, .debug_addr, etc, and .debug_info.dwo, etc) has some
>> minor quirks when it comes to DWARFv5 support.
>>
>> The range-dumping functionality uses DWARFUnit::getAddrOffsetSectionItem
>> on the unit that contains the range attribute (DW_AT_ranges, etc) - so
>> ranges in the .dwo can still read addresses and use them to print the
>> addresses in the range list accounting for relocations and printing section
>> names, etc.
>>
>> Problem is that the split-unit doesn't have the DW_AT_addr_base attribute
>> (it's in the skeleton unit) so getAddrOffsetSectionItem reads from the
>> start of the section, instead of the start of the contribution (after the
>> header).
>>
>> Would be good to fix that - especially if you're interested in supporting
>> non-split split-DWARF (.dwo sections in the object files, more like MachO
>> debug info).
>>
>> Not sure what the right solution to that is - I mean, ultimately it means
>> having llvm-dwarfdump lookup the skeleton CU in the same object file.
>>
>> I guess since this can only apply to the object file (the .dwo sections
>> won't be linked into the executable) - and split-DWARF doesn't support
>> multiple skeleton CUs in a single object file I think... (I remember trying
>> to figure that out with ThinLTO & my memory is a bit hazy) - so maybe it's
>> as simple as "if we're using debug_addr, make sure we're reading/using the
>> skeleton CU which should be the only unit in debug_info in this object".
>>
>> - Dave
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181024/5b08866f/attachment.html>