DWARFv5 rnglists section support in LLVM.

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.

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))