Wrong register names when remote debugging

Wrong register names when remote debugging

[Eric Floehr]

Hi,

Running Ubuntu 20.04 with st-util and gdb-multiarch. I am new to remote
debugging with gdb, but examples show correct register names. When I
connect remotely I see the correct register values, but with x86 register
names:

st-util output:
st-util 1.6.0
2020-05-13T11:28:43 INFO common.c: Loading device parameters....
2020-05-13T11:28:43 INFO common.c: Device connected is: F303 high density
device, id 0x10036446
2020-05-13T11:28:43 INFO common.c: SRAM size: 0x10000 bytes (64 KiB),
Flash: 0x80000 bytes (512 KiB) in pages of 2048 bytes
2020-05-13T11:28:43 INFO gdb-server.c: Chip ID is 00000446, Core ID is
 2ba01477.
2020-05-13T11:28:43 INFO gdb-server.c: Listening at *:4242...
2020-05-13T11:28:59 INFO gdb-server.c: Found 6 hw breakpoint registers
2020-05-13T11:28:59 INFO gdb-server.c: GDB connected.
2020-05-13T11:30:06 ERROR gdb-server.c: cannot recv: -2
2020-05-13T11:30:06 INFO gdb-server.c: Listening at *:4242...

gdb connection:
GNU gdb (Ubuntu 9.1-0ubuntu1) 9.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) target extended-remote :4242
Remote debugging using :4242
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
0x00000000 in ?? ()
(gdb) load main.elf
Loading section .text, size 0x1c lma 0x8000000
Start address 0x08000000, load size 28
Transfer rate: 208 bytes/sec, 28 bytes/write.
(gdb) continue
Continuing.
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
0x00000000 in ?? ()
(gdb) info registers
eax            0x1cb5d1            1881553
ecx            0x0                 0
edx            0x0                 0
ebx            0x0                 0
esp            0x0                 0x0
ebp            0x0                 0x0
esi            0x0                 0
edi            0xdeadbeef          -559038737
eip            0x0                 0x0
eflags         0x0                 [ ]
cs             0x0                 0
ss             0x0                 0
ds             0x0                 0
es             0x20080000          537395200
fs             0xffffffff          -1
gs             0x8000010           134217744
(gdb)

Any thoughts on what is going on?

Thanks!
Eric

Re: Wrong register names when remote debugging

[Eric Floehr]

Well that was silly :-)

The problem was I was still running the non-multiarch "gdb" versus
"gdb-multiarch" command.

Changing to running "gdb-multiarch" solved the problem.

Cheers,
Eric

On Wed, May 13, 2020 at 11:41 AM Eric Floehr <eric@floehr.com> wrote:

> Hi,
>
> Running Ubuntu 20.04 with st-util and gdb-multiarch. I am new to remote
> debugging with gdb, but examples show correct register names. When I
> connect remotely I see the correct register values, but with x86 register
> names:
>
> st-util output:
> st-util 1.6.0
> 2020-05-13T11:28:43 INFO common.c: Loading device parameters....
> 2020-05-13T11:28:43 INFO common.c: Device connected is: F303 high density
> device, id 0x10036446
> 2020-05-13T11:28:43 INFO common.c: SRAM size: 0x10000 bytes (64 KiB),
> Flash: 0x80000 bytes (512 KiB) in pages of 2048 bytes
> 2020-05-13T11:28:43 INFO gdb-server.c: Chip ID is 00000446, Core ID is
>  2ba01477.
> 2020-05-13T11:28:43 INFO gdb-server.c: Listening at *:4242...
> 2020-05-13T11:28:59 INFO gdb-server.c: Found 6 hw breakpoint registers
> 2020-05-13T11:28:59 INFO gdb-server.c: GDB connected.
> 2020-05-13T11:30:06 ERROR gdb-server.c: cannot recv: -2
> 2020-05-13T11:30:06 INFO gdb-server.c: Listening at *:4242...
>
> gdb connection:
> GNU gdb (Ubuntu 9.1-0ubuntu1) 9.1
> Copyright (C) 2020 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
>     <http://www.gnu.org/software/gdb/documentation/>.
>
> For help, type "help".
> Type "apropos word" to search for commands related to "word".
> (gdb) target extended-remote :4242
> Remote debugging using :4242
> warning: No executable has been specified and target does not support
> determining executable automatically.  Try using the "file" command.
> 0x00000000 in ?? ()
> (gdb) load main.elf
> Loading section .text, size 0x1c lma 0x8000000
> Start address 0x08000000, load size 28
> Transfer rate: 208 bytes/sec, 28 bytes/write.
> (gdb) continue
> Continuing.
> ^C
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x00000000 in ?? ()
> (gdb) info registers
> eax            0x1cb5d1            1881553
> ecx            0x0                 0
> edx            0x0                 0
> ebx            0x0                 0
> esp            0x0                 0x0
> ebp            0x0                 0x0
> esi            0x0                 0
> edi            0xdeadbeef          -559038737
> eip            0x0                 0x0
> eflags         0x0                 [ ]
> cs             0x0                 0
> ss             0x0                 0
> ds             0x0                 0
> es             0x20080000          537395200
> fs             0xffffffff          -1
> gs             0x8000010           134217744
> (gdb)
>
> Any thoughts on what is going on?
>
> Thanks!
> Eric
>
>
>
>