Re: [PATCH][gdb/symtab] Handle DW_AT_ranges with DW_FORM_sec_off in partial DIE

[Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>]

On 2021-01-25 1:53 p.m., Bernd Edlinger wrote:
> On 1/25/21 7:12 PM, Simon Marchi wrote:
>>
>>
>> On 2021-01-25 12:42 p.m., Bernd Edlinger wrote:
>>> On 1/25/21 5:36 PM, Simon Marchi wrote:
>>>>> Yes, unfortunately I have not any experience with writing such assembly
>>>>> tests, but I am always impressed when one of you does it though :-)
>>>>>
>>>>> Nevertheless, the test case seems to be stable from gcc-4.8 .. gcc-11,
>>>>> that it fails without the patch and passes with the patch.
>>>>>
>>>>> So is it okay to push my partial symbols test as-is?
>>>>
>>>> My patch here adds a test that uses DW_FORM_sec_offset to point
>>>> to a .debug_rnglists (DWARF5) section.  Maybe that's sufficient,
>>>> but if not I could probably do a DWARF4 equivalent.
>>>>
>>>>   https://sourceware.org/pipermail/gdb-patches/2021-January/175229.html
>>>>
>>>
>>> Yeah, the hardest part on a one-line change like this is always the test case.
>>>
>>> So, I tried this patch on current trunk, but it fails:
>>>
>>> Running /home/ed/gnu/gdb-build-1/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.dwarf2/rnglists-multiple-cus.exp ...
>>> ERROR: Couldn't load rnglists-multiple-cus-dw32 into GDB (GDB internal error).
>>> ERROR: Couldn't load rnglists-multiple-cus-dw64 into GDB (GDB internal error).
>>> Running /home/ed/gnu/gdb-build-1/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.dwarf2/rnglists-sec-offset.exp ...
>>> FAIL: gdb.dwarf2/rnglists-sec-offset.exp: is_64=false: p/x &foo
>>> FAIL: gdb.dwarf2/rnglists-sec-offset.exp: is_64=true: p/x &foo
>>>
>>> This probably means that your test tests more than this single-line change alone?
>>
>> Hmm, with current master (so with Tom's patch merged),
>> gdb.dwarf2/rnglists-sec-offset.exp passes for me.
>>
> 
> That will probably need investigation.
> Let's first check if I applied the corrrect test case,
> see attached patch.txt.

It looks like the right patch (I looked at your second patch.txt).

> 
> tried to do "readelf --debug-dump rnglists-sec-offset-dw32" and
> "readelf --debug-dump rnglists-sec-offset-dw64"
> 
> I used GNU readelf (GNU Binutils) 2.35.1
> 
> I see a warning:
> readelf: Warnung: The .debug_rnglists section contains unsupported offset entry count: 2.
> 
> 
> what does that mean?
> Doesn't that indicate that the debug-info somehow wrong?

I think it's more that readelf is not yet able to read .debug_rnglists
sections with an array of offsets (used when you want to use the
DW_FORM_rnglistx form), probably because gcc does not use produce / use
it.

llvm-dwarfdump can dump it:

    $ llvm-dwarfdump --debug-rnglists testsuite/outputs/gdb.dwarf2/rnglists-sec-offset/rnglists-sec-offset-dw32
    testsuite/outputs/gdb.dwarf2/rnglists-sec-offset/rnglists-sec-offset-dw32:      file format elf64-x86-64
    
    .debug_rnglists contents:
    range list header: length = 0x00000034, format = DWARF32, version = 0x0005, addr_size = 0x08, seg_size = 0x00, offset_entry_count = 0x00000002
    offsets: [
    0x00000008
    0x0000001a
    ]
    ranges:
    [0x0000000000004000, 0x0000000000005000)
    <End of list>
    [0x0000000000004000, 0x0000000000004010)
    <End of list>


Notice "offset_entry_count = 0x00000002" and the two offsets in the
array of offsets.

> It happens pretty reliably when you have a function that contains an error
> handling that looks obvously "unlinkely" to the compiler, because it is guarded
> by an if-condition and calls abort(), while there are also code paths that
> don't call about.  The parts that call abort are then in a separate cold section.

Indeed.  I think it's good to have some tests with optimized code (in
addition to those that use the DWARF assembler), but we can't be too
specific about what we expect the generated code to look like.  For
example, whether a given function is inlined or whether a function is
split in two.  But at least, we can check that we can put a breakpoint
on the function and run there, that is always supposed to work.  And
perhaps a new crazy optimization in GCC version n + 1 will make that
simple use case break, so that will notify us that need to support
something we don't support currently.

Simon