I have seen in Specifying an architecture in gdb-multiarch :
If I compile a C program with any arm compiler (e.g. arm-none-eabi-gcc) and afterwards call gdb-multiarch with the binary as second param(e)ter, it will correctly determine the machine type and I can debug my remote application.
I am using mingw-w64-x86_64-gdb-multiarch 12.1-1
on MINGW64 (MSYS2) on Windows 10; and unfortunately, it seems it cannot determine the architecture. I have built an executable for Pico/RP2040 with gcc
on this same system, and the system sees it as:
$ file myexecutable.elf
myexecutable.elf: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, with debug_info, not stripped
However, if I try to run this in gdb-multiarch, I get:
$ gdb-multiarch myexecutable.elf
GNU gdb (GDB) 12.1
...
warning: A handler for the OS ABI "Windows" is not built into this configuration
of GDB. Attempting to continue with the default armv6s-m settings.
Reading symbols from myexecutable.elf...
(gdb)
Well, as the warning says, it seems that gdb-multiarch
sees this .elf as 'OS ABI "Windows"' - similar to what was noted in Specifying an architecture in gdb-multiarch :
If however I call gdb-multiarch on its own, it will assume my machine type (x86_64) and tries to debug the remote target with the wrong architecture..
... except, here I'm calling gdb-multiarch with the binary as second parameter - and I still have that problem!
The linked question already explains that set architecture arch
from within GDB should work; however, I'm not exactly sure what to enter: file
says this executable is "ARM, EABI5", and I've tried to derive an architecture label from that, which doesn't quite work:
(gdb) set architecture armeabi5
Undefined item: "armeabi5".
... and I'm not that knowledgeable with ARM, so that I'd know exactly what to enter here manually.
Therefore, I would prefer if gdb-multiarch
found the architecture on its own automatically.
How can I persuade gdb-multiarch
to detect the (ARM) architecture of the compiled file correctly?
CodePudding user response:
You may try using a multiarch GDB suitable for use on Intel architectures only.
You can check by starting GDB and entering the following command:
set architecture
. If this is the case, the list of supported architectures will look like this:
(gdb) set architecture
Requires an argument. Valid arguments are i386, i386:x86-64, i386:x64-32, i8086, i386:intel, i386:x86-64:intel, i386:x64-32:intel, auto.
(gdb)
For debugging a cortex-m0
target, I would suggest using the GDB provided with the Arm arm-none-eabi toolchain, arm-none-eabi-gdb
:
(gdb) set architecture
Requires an argument. Valid arguments are arm, armv2, armv2a, armv3, armv3m, armv4, armv4t, armv5, armv5t, armv5te, xscale, ep9312, iwmmxt, iwmmxt2, armv5tej, armv6, armv6kz, armv6t2, armv6k, armv7, armv6-m, armv6s-m, armv7e-m, armv8-a, armv8-r, armv8-m.base, armv8-m.main, armv8.1-m.main, arm_any, auto.
(gdb)
(gdb) set architecture armv6-m
The target architecture is set to "armv6-m".
(gdb)
Architecture for Cortex-M0
/Cortex-M0
is armv6-m
, but I was always able to debug Cortex-M0
programs with GDB without having to use set architecture
.