Re: Removing old symbols when debugging code that relocates itself

Wolfgang Wallner via Gdb <[email protected]>
Newsgroups gmane.comp.gdb.devel
Message-ID <[email protected]>
Hi Shahab,

On 26.05.22 00:13, Shahab Vahedi wrote:
 > Hi Wolfgang,
 >
 > On Wed, May 25, 2022 at 11:14:28PM +0200, Wolfgang Wallner via Gdb wrote:
 >> It seems I can only remove the symbols that I have added with
 >> add-symbol-file, but not the initial ones ...
 >
 > Maybe you could extract the symbol file [1] and then strip it away from
 > the binary [2]. This way, you have to use "add-symbol-file" to add it
 > in different stages and according to what you say you should be able
 > to remove it after each adding.
 >
 > [1]
 > $ objcopy --only-keep-debug uboot.bin uboot.sym
 >
 > [2]
 > $ objcopy --strip-all uboot.bin uboot.strp

Thanks for the feedback!

I tried your recommendations, and while it seems to help somewhat,
unfortunately it does not fully solve my troubles.

Here is what I did:

1) Create the files as you described:

    arm-linux-gnueabihf-objcopy --strip-all u-boot u-boot.strp
    arm-linux-gnueabihf-objcopy --only-keep-debug u-boot my_u-boot.sym

Remark: The U-Boot build already creates a file called 'u-boot.sym', so
I gave my file another name (my_u-boot.sym).
The already existing u-boot.sym file is the symbol table as text file
created by calling 'objdump -t'.

2) I start QEMU as described in my first mail
3) I start GDB using the 'u-boot.strp' ELF file
4) As first command, I add 'my_u-boot.sym' via add-symbol-file

I then step through the code as described in my last mail, but
somehow in this configuration I cannot use GDB's 'until' command.
Using 'until' continues execution, and the temporary breakpoint is
never hit. It is interesting to note that this is *only in assembly*,
using 'until' works fine in C-files!

As a workaround for this issue I set explicit breakpoints.

5) I continue to step through the code, until I reach the relocated code. I
then drop all symbols via 'symbol-file', and add them back for the relocated
location via 'add-symbol-file'.

Showing information about breakpoints shows that there are no duplicate
breakpoints any more --> woohoo :)

    (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   0x47f3c754 arch/arm/lib/relocate.S:134
            breakpoint already hit 1 time

While these breakpoints were set at the old locations, now they already
point
to the symbols at the relocated locations.

But when I try to set a new breakpoint, it is again a duplicate:

    (gdb) break board_init_r
    Breakpoint 3 at 0x1dc28 (2 locations)

    (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   0x47f3c754 arch/arm/lib/relocate.S:134
            breakpoint already hit 1 time
    3       breakpoint     keep y   <MULTIPLE>
    3.1                         y   0x0001dc28 <board_init_r+4>
    3.2                         y   0x47f58c24 in board_init_r at
common/board_r.c:817

So this leaves me with the following questions:

    *) Does anyone know why the 'until' command stopped working with this
       approach in assembly files? Is this expected, or is it a bug?

    *) Why are there still duplicate breakpoints?

    *) Are there other approaches to deal with relocated code?
       While the objcopy steps have helped me, for a more permanent
       workflow I would like to avoid them (e.g. it would be nice to
       directly set up a debug environment in an IDE, and any required
       extra steps between compilation and debugging would make that more
       complicated)

regards, Wolfgang

Remark: I think there was a typo in my initial mail. The breakpoint in
relocate.S should be in line 134, not line 118.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.