From: Wolfgang Wallner <wolfgang-wallner@gmx.at>
To: gdb@sourceware.org
Subject: Removing old symbols when debugging code that relocates itself
Date: Wed, 25 May 2022 23:14:28 +0200 [thread overview]
Message-ID: <d62143d5-9fba-2a17-8713-6c9fd0bcda94@gmx.at> (raw)
Hi all,
I have a question regarding adding and removing symbols.
I try to learn more about the inner workings of the U-Boot bootloader
[1] by stepping through it's execution.
There are some QEMU machines that are supported by U-Boot, and I choose
to use the 'virt' machine for ARM for my exercise.
The tricky part is that U-Boot relocates itself during runtime to
another address and continues execution from there.
I can successfully do the following:
* step through the code until relocation
* add the ELF file again (add-symbol-file) at the relocated address
* continue to step through the code at the new location
However, after relocation something is strange with symbols and
breakpoints. I would like to remove the symbols that I don't need any
more, but I can't figure out how to do that properly. What I have tried
is calling 'symbole-file' without arguments and 'remove-symbol-file'.
It seems I can only remove the symbols that I have added with
add-symbol-file, but not the initial ones ...
I will add a detailed description of what I'm doing below.
I hope you can help me here to figure it out, or point me to the
relevant documentation.
regards, Wolfgang
[1] https://source.denx.de/u-boot/u-boot
------------------------------------------------------------------
Detailed description:
I use revision f83bd23e2 (current master of a few day ago) of U-Boot.
git clone https://source.denx.de/u-boot/u-boot.git
git checkout f83bd23e2
Then I cross-compile U-Boot for the QEMU ARM 'virt' machine:
cd u-boot
export CROSS_COMPILE=arm-linux-gnueabihf-
make qemu_arm_defconfig
make
This provides me with the files 'u-boot' (ELF with debug info) and
'u-boot.bin (binary file for execution in QEMU).
I start QEMU as follows:
qemu-system-arm -machine virt -nographic -bios u-boot.bin -s -S
The simulated machine will have 128MB of RAM by default, which will be
mapped starting from address 0x40000000.
Mapped to address 0x00000000 is the simulated flash memory containing
the binary file passed via the "-bios" parameter (u-boot.bin).
In another shell I start gdb and connect to QEMU's gdb server:
gdb-multiarch -q u-boot
(gdb) target remote :1234
The function which carries out the relocation is called relocate_code
and is called from within the file crt0.S.
I set a breakpoint right before it is called:
(gdb) break crt0.S:156
Showing the current breakpoints with 'info breakpoints' gives me the
following (expected) result:
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x00001668 arch/arm/lib/crt0.S:156
I 'continue' the execution and the breakpoint within crt0.S is hit.
The relocation address is calculated during runtime, so let's print it
via 'print/x gd->relocaddr':
(gdb) print/x gd->relocaddr
$1 = 0x47f3b000
The code will be relocated to RAM at addresss 0x47f3b000, which is at
the upper end of the simulated 128MB.
Next I step into relocate_code, run until its end at line 118, and print
the program counter (register r15 on ARM):
(gdb) step
(gdb) until 118
(gdb) print $r15
$2 = (void (*)()) 0x1754 <relocate_code+108>
We are still within the simulated flash, but the next instruction
(returning from relocate_code) will jump to the relocated code in RAM.
I load the file 'u-boot' ELF-file again via add-symbol-file, this time
at the relocation addresss 0x47F3B000:
(gdb) add-symbol-file u-boot 0x47F3B000
Stepping out of relocate_code and printing the program counter again:
(gdb) step
?? () at arch/arm/lib/crt0.S:162
162 bl relocate_vectors
(gdb) print $r15
$3 = (void (*)()) 0x47f3c66c
As expected, we are now at the relocated location, and I can step
through the code.
But now the trouble starts. Printing the currently set breakpoints shows
that some breakpoints are set multiple times.
This is expected, as I have loaded the same symbols at two different places.
info breakpoints
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
breakpoint already hit 1 time
1.1 y 0x00001668 arch/arm/lib/crt0.S:156
1.2 y 0x47f3c668 arch/arm/lib/crt0.S:156
At this point, I don't need the symbol at address 0x00000000 any more,
and I would like to remove them.
However, I can't figure out how.
I have tried remove-symbol-file and symbol-file without arguments.
If anything it seems I'm able to remove the symbols from the second
location (at 0x47F3B000), but not from the first location (at 0x00000000).
Any tips on how to remove the now unneeded symbols?
Adding new breakpoints also leads to multiple breakpoints:
(gdb) break board_init_r
Breakpoint 2 at 0x1dc24: board_init_r. (2 locations)
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
breakpoint already hit 1 time
1.1 y 0x00001668 arch/arm/lib/crt0.S:156
1.2 y 0x47f3c668 arch/arm/lib/crt0.S:156
2 breakpoint keep y <MULTIPLE>
2.1 y 0x0001dc24 in board_init_r at
common/board_r.c:817
2.2 y 0x47f58c24 in board_init_r at
common/board_r.c:817
If I try to drop all symbols and add the relocated ones again I get the
following:
(gdb) symbol-file
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <PENDING> crt0.S:156
breakpoint already hit 1 time
2 breakpoint keep y <PENDING> board_init_r
(gdb) add-symbol-file u-boot 0x47F3B000
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x47f3c668 arch/arm/lib/crt0.S:156
breakpoint already hit 1 time
2 breakpoint keep y <MULTIPLE>
2.1 y 0x0001dc28 <board_init_r+4>
2.2 y 0x47f58c24 in board_init_r at
common/board_r.c:817
So, somehow the old symbols are still known, but the debug information
(file location) is gone ... ?
next reply other threads:[~2022-05-25 21:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-25 21:14 Wolfgang Wallner [this message]
2022-05-25 22:13 ` Shahab Vahedi
2022-05-26 19:28 ` Wolfgang Wallner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d62143d5-9fba-2a17-8713-6c9fd0bcda94@gmx.at \
--to=wolfgang-wallner@gmx.at \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).