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

[David Blaikie via llvm-dev]

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/d4a3444a/attachment.html>