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

[Andrew Burgess <aburgess@redhat.com>]

Simon Marchi <simark@simark.ca> writes:

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

I'm never going to complain about more information.  Especially not in
maintainer commands.

Just wanted to make sure my use case was noted.

Thanks,
Andrew