Sec 3.1 - Fedora package does not exist

[anthonyjmartinez]

arm-none-eabi-gdb appears to have ceased existing in default (or RPMFusion) repositories somewhere around F30, recent discussion around the topic seems to indicate it's not even necessary: https://bugzilla.redhat.com/show_bug.cgi?id=1859627#c23

[sirhcel]

Thank you for pointing that out @anthonyjmartinez! I created PR #367 for guiding Fedora users to use GDB from a pre-built toolchain from ARM instead.

[anthonyjmartinez]

@sirhcel thanks for the speedy update.

I think it's worth noting that this JustWorks™ with the normal gdb from Fedora 33:

OpenOCD gave a warning that stlink.cfg should be used (it works either way though):

[user@projects ~]$ sudo openocd -f /usr/share/openocd/scripts/interface/stlink.cfg -f /usr/share/openocd/scripts/target/stm32f3x.cfg 
Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 1000 kHz
Info : STLINK V2J37M26 (API v2) VID:PID 0483:374B
Info : Target voltage: 2.905338
Info : stm32f3x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for stm32f3x.cpu on 3333
Info : Listening on port 3333 for gdb connections
Info : accepting 'gdb' connection on tcp/3333
Info : device id = 0x10036422
Info : flash size = 256kbytes

GDB says to use extended-remote instead of remote

[user@projects 05-led-roulette]$ gdb -q -ex "target extended-remote :3333" target/thumbv7em-none-eabihf/debug/led-roulette
Reading symbols from target/thumbv7em-none-eabihf/debug/led-roulette...
Remote debugging using :3333
warning: Remote gdbserver does not support determining executable automatically.
RHEL <=6.8 and <=7.2 versions of gdbserver do not support such automatic executable detection.
The following versions of gdbserver support it:
- Upstream version of gdbserver (unsupported) 7.10 or later
- Red Hat Developer Toolset (DTS) version of gdbserver from DTS 4.0 or later (only on x86_64)
- RHEL-7.3 versions of gdbserver (on any architecture)
0x080039ba in ?? ()
(gdb)

Loading works as well:

[user@projects 05-led-roulette]$ cargo run --target thumbv7em-none-eabihf
    Finished dev [unoptimized + debuginfo] target(s) in 0.02s
     Running `gdb -q /home/user/Projects/learning/discovery/target/thumbv7em-none-eabihf/debug/led-roulette`
Reading symbols from /home/user/Projects/learning/discovery/target/thumbv7em-none-eabihf/debug/led-roulette...
(gdb) target extended-remote :3333
Remote debugging using :3333
warning: Remote gdbserver does not support determining executable automatically.
RHEL <=6.8 and <=7.2 versions of gdbserver do not support such automatic executable detection.
The following versions of gdbserver support it:
- Upstream version of gdbserver (unsupported) 7.10 or later
- Red Hat Developer Toolset (DTS) version of gdbserver from DTS 4.0 or later (only on x86_64)
- RHEL-7.3 versions of gdbserver (on any architecture)
0x080039ba in ?? ()
(gdb) load
Loading section .vector_table, size 0x194 lma 0x8000000
Loading section .text, size 0x1f4c lma 0x8000194
Loading section .rodata, size 0x514 lma 0x80020e0
Start address 0x08000194, load size 9716
Transfer rate: 15 KB/sec, 3238 bytes/write.

[sirhcel]

Thank you @anthonyjmartinez and @hargoniX (#367 (comment)) for showing that Fedora's gdb package works a treat! I think it would be helpful for other Fedora users to use this GDB as well and to get around the manual installation of the toolchain from ARM.

What about updating the instructions one more time? I have no Fedora installation at hand. But could one of you update https://github.com/rust-embedded/discovery/blob/79fe204baf28d0626002ad49db9ba3fb3f525996/src/03-setup/linux.md to make the setup for Fedora users more comfy again?

[anthonyjmartinez]

@sirhcel sure, I can draft something tomorrow for the Fedora part.

[sirhcel]

Awesome @anthonyjmartinez! Thank you very much! :)