makefiles/tools/gdb.inc.mk: prefer $(target)-gdb over gdb-multiarch

[maribu]

Contribution description

In an ideal world everyone would just install gdb-multiarch and be happy. However, some MCUs need magic GDB versions sprinkled with unicorn-stardust-Espressif-patches...

Since there is little reason to have $(target)-gdb installed in addition to gdb-multiarch if gdb-multiarch would work fine, let's assume the user wants to use $(target)-gdb when present over gdb-multiarch.

Testing procedure

USEMODULE=esp_jtag make BOARD=esp32-ethernet-kit-v1_2 PROGRAMMER=openocd OPENOCD=openocd-esp32 debug -C examples/default

In master:

/home/maribu/Repos/software/RIOT/dist/tools/openocd/openocd.sh debug /home/maribu/Repos/software/RIOT/examples/default/bin/esp32-ethernet-kit-v1_2/default.elf
### Starting Debugging ###
Open On-Chip Debugger v0.11.0-snapshot (2022-10-21-10:40)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Reading symbols from /home/maribu/Repos/software/RIOT/examples/default/bin/esp32-ethernet-kit-v1_2/default.elf...
Remote debugging using :3333
Remote 'g' packet reply is too long (expected 180 bytes, got 420 bytes): 00040040000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000004004096fec51c2500060000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

With this PR:

/home/maribu/Repos/software/RIOT/dist/tools/openocd/openocd.sh debug /home/maribu/Repos/software/RIOT/examples/default/bin/esp32-ethernet-kit-v1_2/default.elf
### Starting Debugging ###
DBG="xtensa-esp32-elf-gdb", GDB="xtensa-esp32-elf-gdb", DBG_FLAGS="-q -ex "tar ext :3333" "
Open On-Chip Debugger v0.11.0-snapshot (2022-10-21-10:40)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Reading symbols from /home/maribu/Repos/software/RIOT/examples/default/bin/esp32-ethernet-kit-v1_2/default.elf...
Remote debugging using :3333
0x40000400 in ?? ()
(gdb) start
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Temporary breakpoint 1 at 0x400d0024: file /data/riotbuild/riotbase/examples/default/main.c, line 37.
Note: automatically using hardware breakpoints for read-only addresses.
Starting program: /home/maribu/Repos/software/RIOT/examples/default/bin/esp32-ethernet-kit-v1_2/default.elf 
[esp32.cpu0] Target halted, PC=0x400D0024, debug_reason=00000001
Set GDB target to 'esp32.cpu0'

Temporary breakpoint 1, main () at /data/riotbuild/riotbase/examples/default/main.c:37
37	{
(gdb) show arch
The target architecture is set to "auto" (currently "xtensa").
(gdb) 

quit
A debugging session is active.

	Inferior 1 [Remote target] will be detached.

Quit anyway? (y or n) y

Detaching from program: /home/maribu/Repos/software/RIOT/examples/default/bin/esp32-ethernet-kit-v1_2/default.elf, Remote target
[Inferior 1 (Remote target) detached]

Issues/PRs references

#18359 (comment)

[gschorcht]

I'm not sure whether we should use dirty words in comments. I don't know if it's really a bad upstream policy of Espressif or if it's just too difficult to get changes into the upstream repository. I'm not familiar with the process for GDB.

[maribu]

I had excellent experience with a bug I recently stumbled over with GDBs integrated disassembler. The GDB folks was quick to reply, professional and welcoming.

Note that ESPs are the only CPUs I am aware of that do not work with gdb-multiarch. It works for any ARM version, any RISC-V version, any PowerPC, any MIPS, any z80 / 8080, any MSP430. It works out of the box for strange beasts like s390 / s390x.

I wouldn't be surprised if the ESPs are the only human made MCUsin the universe sold in quantities > 10K currently unsupported by upstream GDB.

The amount of time to invested and pain and frustration tolerance needed to get tools working with ESP is absolutely unparalleled by any other platform.

I do agree that the Xtensa architecture is surprisingly customizable and the effort to implement proper multilib support is likely higher, especially due to the lack of proper classification of variants (e.g. much unlike ARM / RISC-V). Still, not even non-multilib builds of standard tools are compatible with ESPs.

And with the ESP32C3 it is the exact same pain. There is not reason why a magic riscv32-esp-elf-gcc is needed, when there are standard RISC-V toolchains in any major distro provided. I also have very little sympathy for Espressif's choice to use a custom interrupt controller interface over the standard CLIC / PLIC every other vendors uses (I think that in addition to the spec being license free there are even license free implementations they could have used).

The issue of this lack of upstream support becomes apparent when looking at the state of the official toolchains: They still ship ancient versions of GCC and newlib. And for ESP8266 it is unlikely that the official toolchain will ever get an update again.

I am pretty sure that Espressif are the ones to blame. But I'll update the documentation anyway.

[gschorcht]

I do agree that the Xtensa architecture is surprisingly customizable and the effort to implement proper multilib support is likely higher,

Maybe the situation will become better in the future since Espressif seems to be shifting to RISC-V based SoCs according to the news on hackster.io six months ago. ESP32-C2 and ESP32-C3 were the first RISC-V based SoCs, ESP32-C6 and ESP32-H2 will be the next. Unfortunately, they also provide their own toolchains for RISC-V based SoCs.

And with the ESP32C3 it is the exact same pain. There is not reason why a magic riscv32-esp-elf-gcc is needed, when there are standard RISC-V toolchains in any major distro provided.

I fully agree. When I was experimenting with ESP32-C3 the first time, I tried to use the riscv-none-embed toolchain, but I had no success. On one hand because the source code is incompatible with newer GCC versions and we are not responsible to fix it via a bunch of patches. On the other hand because the binary blobs are compiled with Espressif's toolchain, which is configured differently regarding the retargetable locking and thread model.

I also have very little sympathy for Espressif's choice to use a custom interrupt controller interface over the standard CLIC / PLIC every other vendors uses.

I also tried to use the existing architecture specific implementation in cpu/riscv_common. Espressif's interrupt controller was only one problem. Another problem was that ESP-IDF uses another context frame structure which is not compatible with the context frame in cpu/riscv_common.

[gschorcht]

Feel free to squash directly.

[riot-ci]

Murdock results

✔️ PASSED

b9b63da makefiles/tools/gdb.inc.mk: prefer $(target)-gdb over gdb-multiarch

Success	Failures	Total	Runtime
1991	0	1991	06m:48s

Artifacts

• Documentation preview

This only reflects a subset of all builds from https://ci-prod.riot-os.org. Please refer to https://ci.riot-os.org for a complete build for now.

[maribu]

This sadly didn't make it into the release. If we end up creating a point release, I think it would be nice to backport it

[maribu]

Backport provided in #19020