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

Thu Oct 25 01:57:42 PDT 2018

Cool, thanks for the fix! :)

Best regards,
George | Developer | Access Softek, Inc
________________________________
От: David Blaikie <dblaikie at gmail.com>
Отправлено: 25 октября 2018 г. 1:47
Кому: wolfgang.pieb at sony.com
Копия: paul.robinson at sony.com; George Rimar; llvm-dev at lists.llvm.org
Тема: Re: [llvm-dev] llvm-dwarfdump on whole-split-file fails to account for indirection through skeleton

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
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<mailto:dblaikie at gmail.com>> wrote:
On Wed, Oct 24, 2018 at 1:11 PM <wolfgang.pieb at sony.com<mailto: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<mailto: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<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/20181025/bf60ed2a/attachment-0001.html>