[llvm-dev] DWARFv5 rnglists section support in LLVM.

David Blaikie via llvm-dev llvm-dev at lists.llvm.org
Mon Dec 2 08:23:34 PST 2019

Yep, that's intentional.

It's useful to have the ranges for the CU in the .o file/linked executable
(& I imagine it's /necessary/ for things like gdb_index) to allow quick
lookup (without consulting .dwo/.dwp files) of which CU contains debug info
for a certain program address.

So the CU's DW_AT_ranges is in the skeleton CU and refers to debug_rnglists
in the .o/executable. All other ranges are in the DIEs in the .dwo file and
refer to debug_rnglists.dwo in there.

Check this example: https://godbolt.org/z/wWkU8V - the lexical scope for
the 'if' statement is perhaps buggy (should the call to 'f2()' be within
the lexical scope or not? unclear to me) but it's good for demonstrating
this issue - the lexical_scope's range is in debug_rnglist.dwo, but the
CU's ranges are in the debug_rnglist section.

(I guess we could optimize the .o/linked executable side of this a bit by
not using rnglistx there (& using a direct relocation to the range list) -
since there's exactly one range so there's no opportunity to benefit from
sharing the rnglists_base relocation (because there's only one range))

On Fri, Nov 29, 2019 at 3:59 AM Sourabh Singh Tomar <sourav0311 at gmail.com>

> Hello Everyone,
> LLVM now support DWARFv5 rangelist section rnglists and rnglists.dwo. But
> while working on a typical test case, I noticed --
> rnglists/rnglists.dwo both are populated in primary object and DWO object
> respectively, when we compile with "-gdwarf-5 -gsplit-dwarf". Is this
> desired behavior?
> *Referring Spec, Fig B.2 Split DWARF section relationships* -- depicts,
> for split case, their has to be rnglists.dwo section located in DWO object.
> Not both rnglists{in primary object} and rnglists.dwo{in DWO object}.
> This is also contrary, WRT to loclists/loclist.dwo. Here generation is
> fine split mode, only loclists.dwo gets populated in DWO object. And no
> loclists section in primary object.
> Is this behavior desirable/part of functionality?
> Thank You,
> Sourabh Singh Tomar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191202/1360fe6f/attachment.html>

More information about the llvm-dev mailing list