Re: [PATCH] gdb: make "maintenance info line-table" show relocated addresses again

[Simon Marchi <simark@simark.ca>]

On 3/20/23 17:35, Andrew Burgess via Gdb-patches wrote:
> Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes:
> 
>> Commit 1acc9dca423f ("Change linetables to be objfile-independent")
>> changed "maintenance info line-table" to print unrelocated addresses
>> instead of relocated.  This breaks a few tests on systems where that
>> matters.  The ones I see are:
>>
>>     Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/consecutive.exp ...
>>     FAIL: gdb.base/consecutive.exp: stopped at bp, 2nd instr (missing hex prefix)
>>     Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/async.exp ...
>>     FAIL: gdb.base/async.exp: stepi&
>>     FAIL: gdb.base/async.exp: nexti&
>>     FAIL: gdb.base/async.exp: finish&
>>
>> These tests run "maintenance info line-table" to record the address of
>> some lines, and then use these addresses in expected patterns.
>>
>> For the time being, I suggest simply reverting the command to show
>> relocated addresses.
> 
> This makes sense to me.  When I use 'maint info line-table' it's usually
> because I want to try and match up the line table with the code being
> executed, so having the relocated addresses would be far more useful.
> 
> Reviewed-By: Andrew Burgess <aburgess@redhat.com>

What would you think about showing both, like this?

    (gdb) maintenance info line-table
    objfile: /home/simark/build/binutils-gdb/gdb/a.out ((struct objfile *) 0x614000007240)
    compunit_symtab: test.c ((struct compunit_symtab *) 0x621000123890)
    symtab: /home/simark/build/binutils-gdb/gdb/test.c ((struct symtab *) 0x621000123910)
    linetable: ((struct linetable *) 0x62100015fc20):
    INDEX  LINE   REL-ADDRESS        UNREL-ADDRESS      IS-STMT PROLOGUE-END
    0      6      0x0000555555555119 0x0000000000001119 Y
    1      7      0x000055555555511d 0x000000000000111d Y
    2      8      0x0000555555555123 0x0000000000001123 Y
    3      END    0x0000555555555125 0x0000000000001125 Y

I think it could be useful to match the unrelocated address with what
you see in the DWARF info.  If the objfile is not position-independent,
or not relocated yet, the two columns show the same values.

Simon