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

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

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.

Simon