diff options
author | Simon Marchi <simon.marchi@polymtl.ca> | 2021-10-04 18:16:40 +0200 |
---|---|---|
committer | Tom de Vries <tdevries@suse.de> | 2021-10-04 18:16:40 +0200 |
commit | b0b8879e292218bfb27584515e98a46379c9c666 (patch) | |
tree | 3789b058a0b993a6949d3f681a63a70bde644bad /gdbserver | |
parent | b84aaadaf8b774630b90d91d23e15c9f521fbeee (diff) | |
download | gdb-b0b8879e292218bfb27584515e98a46379c9c666.zip gdb-b0b8879e292218bfb27584515e98a46379c9c666.tar.gz gdb-b0b8879e292218bfb27584515e98a46379c9c666.tar.bz2 |
[gdb/symtab] Use unrelocated addresses in call_site
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
We could fix this by adding the missing call_site relocation in
objfile_relocate1.
This solution however is counter-trend in the sense that we're trying to
work towards the situation where when starting two instances of an executable,
we need only one instance of debug information, implying the use of
unrelocated addresses.
So, fix this instead by using unrelocated addresses in call_site info.
Tested on x86_64-linux.
This fixes all remaining unix/-fno-PIE/-no-pie vs unix/-fPIE/-pie
regressions, like f.i. PR24892.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24892
Co-Authored-By: Tom de Vries <tdevries@suse.de>
Diffstat (limited to 'gdbserver')
0 files changed, 0 insertions, 0 deletions