[llvm-dev] Collecting address ranges in DWARFUnit::collectAddressRanges.

Robinson, Paul via llvm-dev llvm-dev at lists.llvm.org
Thu Nov 16 14:21:47 PST 2017

Ah right, the GNU forms.  Yes, I did forget about those.  So, reading the DWO units can be necessary.

From: David Blaikie [mailto:dblaikie at gmail.com]
Sent: Thursday, November 16, 2017 12:20 PM
To: Robinson, Paul
Cc: George Rimar; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] Collecting address ranges in DWARFUnit::collectAddressRanges.

On Thu, Nov 16, 2017 at 11:44 AM Robinson, Paul <paul.robinson at sony.com<mailto:paul.robinson at sony.com>> wrote:
There's no requirement that DW_AT_ranges (or high/low_pc) appear on the skeleton CU rather than the DWO CU. So it's quite possible that to get the address ranges covered by the CU one would need to look in the DWO, I think?

Is that not correct/have I misunderstood something there?
The DWO isn't supposed to contain addresses (because it isn't supposed to contain relocations).  In DWARF 5 the DWO can have FORM_addrx references to the .debug_addr section in the main .o file, which allows the DWO to contain DIEs/attributes that should have address values, because the actual address values are still in the .o file; but before that anything that's an address really can't go into the DWO.

DWOs didn't exist (in a standard form) before DWARF 5, right? Insofar as they did exist (in a non-standard form) they have always supported FORM_addr_index to reference addresses in .debug_addr in the main .o.

But the low_pc/high_pc/ranges attributes would appear in the .dwo, using a FORM_addr_index/FORM_addrx - so if you want to collect the address range of a CU you might need to load the .dwo to do so. That's the crux of what I was getting at: To get the address range a CU covers, you may need to read the .dwo.

Unless I am also misunderstanding something…

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171116/c3bb9bc8/attachment.html>

More information about the llvm-dev mailing list