Re: [PATCH 4/4] [gdb/symtab] Use unrelocated addresses in call_site

[Tom de Vries via Gdb-patches <gdb-patches@sourceware.org>]

On 10/1/21 10:56 PM, Simon Marchi wrote:
> On 2021-10-01 08:33, Tom de Vries via Gdb-patches wrote:
>> From: Simon Marchi <simon.marchi@polymtl.ca>
>>
>> Consider test-case gdb.trace/entry-values.exp with target board
>> unix/-fPIE/-pie.
>>
>> Using this command we have an abbreviated version, and can see the
>> correct
>> @entry values for foo:
>> ...
>> $ gdb -q -batch outputs/gdb.trace/entry-values/entry-values \
>>   -ex start \
>>   -ex "break foo" \
>>   -ex "set print entry-values both" \
>>   -ex continue
>> Temporary breakpoint 1 at 0x679
>>
>> Temporary breakpoint 1, 0x0000555555554679 in main ()
>> Breakpoint 2 at 0x55555555463e
>>
>> Breakpoint 2, 0x000055555555463e in foo (i=0, i@entry=2, j=2, j@entry=3)
>> ...
>>
>> Now, let's try the same again, but run directly to foo rather than
>> stopping at
>> main:
>> ...
>> $ gdb -q -batch outputs/gdb.trace/entry-values/entry-values \
>>   -ex "break foo" \
>>   -ex "set print entry-values both" \
>>   -ex run
>> Breakpoint 1 at 0x63e
>>
>> Breakpoint 1, 0x000055555555463e in foo (i=0, i@entry=<optimized out>, \
>>   j=2, j@entry=<optimized out>)
>> ...
>>
>> So, what explains the difference?  Noteworthy, this is a dwarf assembly
>> test-case, with debug info for foo and bar, but not for main.
>>
>> In the first case:
>> - we run to main
>> - this does not trigger expanding debug info, because there's none for
>> main
>> - we set a breakpoint at foo
>> - this triggers expanding debug info.  Relocated addresses are used in
>>   call_site info (because the exec is started)
>> - we continue to foo, and manage to find the call_site info
>>
>> In the second case:
>> - we set a breakpoint at foo
>> - this triggers expanding debug info.  Unrelocated addresses are used in
>>   call_site info (because the exec is not started)
>> - we run to foo
>> - this triggers objfile_relocate1, but it doesn't update the call_site
>>   info addresses
>> - we don't manage to find the call_site info
> 
> Thanks for this explanation, I had not realized the difference in
> behavior here.
> 
> The patch LGTM.

Thanks for the review.  Committed.

Thanks,
- Tom