stlink: st-util: GDB breakpoints do not break at appropriate location

• Programmer/board type: NUCLEO-F091RC [stlink-v2-1]
• Programmer firmware version: V2J37M26
• Operating system and version: Linux
• Stlink tools version: v1.6.1
• Stlink commandline tool name: st-util
• Target chip (and board if applicable): STM32F091RC

Description: When attempting to break at a particular point in the code, it seems a GDB session will instead break at a completely different location. The location of the break is consistent, but it is not the correct location. When using OpenOCD as the debugging bridge, the break occurs in the correct location.

Commandline-Output:

user@hostname:~
➜ st-util
st-util
2020-07-31T14:17:18 INFO common.c: F09X: 32 KiB SRAM, 256 KiB flash in at least 2 KiB pages.
2020-07-31T14:17:18 INFO gdb-server.c: Listening at *:4242...

user@hostname:oresat-firmware/src/f0/app_template on  master [⇡!]
➜ arm-none-eabi-gdb build/app_template.elf
GNU gdb (GDB) 9.2
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 "--host=x86_64-pc-linux-gnu --target=arm-none-eabi".
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"...
Reading symbols from build/app_template.elf...
(gdb) tar ext localhost:4242
Remote debugging using localhost:4242
CO_NMT_process (NMT=0x20000988 <COO_CANmodule_txArray0+192>, timeDifference_us=<optimized out>, HBtime_ms=<optimized out>, NMTstartup=134218129, errorRegister=147 '\223', errorBehavior=0x8000193 <VectorBC> <incomplete sequence \360>, timerNext_us=0x8000193 <VectorBC>)
    at ../../../common/CANopenNode/301/CO_NMT_Heartbeat.c:232
232         if (NMT->operatingState == CO_NMT_INITIALIZING) {
(gdb) load
Loading section .vectors, size 0xc0 lma 0x8000000
Loading section .text, size 0x7088 lma 0x80000c0
Loading section .rodata, size 0xb24 lma 0x8007148
Loading section .ARM.exidx, size 0x8 lma 0x8007c6c
Loading section .data, size 0x2b0 lma 0x8007c74
Start address 0x08000190, load size 32548
Transfer rate: 15 KB/sec, 5424 bytes/write.
(gdb) kill
Kill the program being debugged? (y or n) y
[Inferior 1 (Remote target) killed]
(gdb) b CO_CANsend
Breakpoint 1 at 0x8001aa0: file ../../../common/CO_driver.c, line 230.
(gdb) run
Starting program: /home/user/Projects/PSAS/oresat-firmware/src/f0/app_template/build/app_template.elf
Note: automatically using hardware breakpoints for read-only addresses.

Program received signal SIGTRAP, Trace/breakpoint trap.
CO_NMT_process (NMT=0x20000988 <COO_CANmodule_txArray0+192>, timeDifference_us=<optimized out>, HBtime_ms=<optimized out>, NMTstartup=134218129, errorRegister=147 '\223', errorBehavior=0x8000193 <VectorBC> <incomplete sequence \360>, timerNext_us=0x8000193 <VectorBC>)
    at ../../../common/CANopenNode/301/CO_NMT_Heartbeat.c:232
232         if (NMT->operatingState == CO_NMT_INITIALIZING) {
(gdb) c
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
CO_NMT_process (NMT=0x20000988 <COO_CANmodule_txArray0+192>, timeDifference_us=<optimized out>, HBtime_ms=<optimized out>, NMTstartup=134218129, errorRegister=147 '\223', errorBehavior=0x8000193 <VectorBC> <incomplete sequence \360>, timerNext_us=0x8000193 <VectorBC>)
    at ../../../common/CANopenNode/301/CO_NMT_Heartbeat.c:232
232         if (NMT->operatingState == CO_NMT_INITIALIZING) {
(gdb)

Expected/description:

It is expected that the debug session breaks at the appropriate line in the appropriate file, which is at address 0x8001aa0. However, it does not break here, and instead it always seems to break at completely different locations.

It almost seems as if the addresses reported back are off in some way, because (for example) OpenOCD reports that it was last idling at address 0x08002462, which is where the system waits for an interrupt. However, with st-util, it always seems to think it is idling on a movs instruction in the middle of a thread starting function.

An example of equivalent expected output from OpenOCD is below:

user@hostname:oresat-firmware/src/f0/app_template on  master [⇡!]
➜ make gdb
arm-none-eabi-gdb -q /home/user/Projects/PSAS/oresat-firmware/src/f0/app_template/./build/app_template.elf -cd ../../../boards/ST_NUCLEO64_F091RC -x gdboocd.cmd
Reading symbols from /home/user/Projects/PSAS/oresat-firmware/src/f0/app_template/./build/app_template.elf...
Open On-Chip Debugger 0.10.0+dev-01365-g583a65644-dirty (2020-07-30-21:27)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
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:3752
Info : Target voltage: 3.254104
Info : stm32f0x.cpu: hardware has 4 breakpoints, 2 watchpoints
Info : starting gdb server for stm32f0x.cpu on pipe
Info : accepting 'gdb' connection from pipe
target halted due to debug-request, current mode: Thread
xPSR: 0x41000000 pc: 0x08002462 psp: 0x20001ae8
Info : device id = 0x10006442
Info : flash size = 256kbytes
Warn : Prefer GDB command "target extended-remote pipe" instead of "target remote pipe"
0x08002462 in port_wait_for_interrupt () at ../../../ChibiOS/os/common/ports/ARMCMx/chcore_v6m.h:458
458   __WFI();
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Unable to match requested speed 1000 kHz, using 950 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x08000190 msp: 0x20000200
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x08000190 msp: 0x20000200
(gdb) b CO_CANsend
Breakpoint 1 at 0x8001aa0: file ../../../common/CO_driver.c, line 230.
(gdb) c
Continuing.
Note: automatically using hardware breakpoints for read-only addresses.
Error: No symbols for ChibiOS

Breakpoint 1, CO_CANsend (CANmodule=0x20000758 <COO_CANmodule>, buffer=0x20000988 <COO_CANmodule_txArray0+192>) at ../../../common/CO_driver.c:230
230 {
(gdb)

The GDB script used for the OpenOCD session is as follows:

target remote | openocd -f oocd.cfg -c "gdb_port pipe"
monitor stm32f0x.cpu configure -rtos chibios
monitor reset halt