Pause (SIGINT) non-functional when using arm-none-eabi-gdb and openocd to debug embedded ARM target.

[davidlenfesty]

Describe the bug I cannot use the pause behaviour while debugging a remote target, it sends SIGINT which simply gets interpreted as Quit in the GDB prompt. I can work around it by entering interrupt in the GDB window but that is obviously not ideal.

I've tested the same workflow (ish) just running a local C program and it appears to function correctly.

To Reproduce Steps to reproduce the behavior:

1. Install arm-none-eabi from the arm toolchain
2. Launch OpenOCD and connect to target
3. Launch with `gdbgui -g arm-none-eabi-gdb myproject.elf
4. Connect to openocd by entering target extended-remote :3333 in GDB window.
5. Load fw with load in GDB window (if not flashed, if it is flashed the reset functionality works fine)
6. Begin running by clicking continue
7. Attempt to stop with pause button, or send SIGINT.

Expected behavior I would expect to see the program halt and sent a proper interrupt, but the button does nothing.

Screenshots

GDB log (the interrupt that was sent was manually entered):

running command: arm-none-eabi-gdb

GNU gdb (GNU Arm Embedded Toolchain 10.3-2021.10) 10.2.90.20210621-git
Copyright (C) 2021 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-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://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".
New UI allocated
(gdb) target extended-remote :3333
Remote debugging using :3333
Note: automatically using hardware breakpoints for read-only addresses.
canard_try_rx () at source/can.c:305
305       if (CAN_RF0R(BX_CAN1_BASE) & CAN_RF0R_FMP0_MASK) {
(gdb) load
Loading section .text, size 0x74c0 lma 0x8000000
Loading section .data, size 0x6c lma 0x80074c0
Start address 0x08002f4c, load size 29996
Transfer rate: 18 KB/sec, 9998 bytes/write.
(gdb) 
Breakpoint 1, main () at led_driver.c:90
90        rcc_periph_clock_enable(RCC_GPIOA);
Quit
(gdb) Quit
(gdb) interrupt
(gdb) 
Program received signal SIGINT, Interrupt.
canard_send_tx () at source/can.c:283
283         if (rc >= 0) {
(gdb) Quit
(gdb)

gdbgui output:

gdbgui output (read-only)
Copy/Paste available in all terminals with ctrl+shift+c, ctrl+shift+v
Started new gdb process, pid 193807
sent signal SIGINT (2) to process id 193807
Cannot execute this command while the selected thread is running.
Cannot execute this command while the selected thread is running.
Cannot execute this command while the selected thread is running.
sent signal SIGINT (2) to process id 193807
Cannot execute this command while the target is running.nUse the "interrupt" command to stop the targetnand then try again.
Selected thread is running.
Selected thread is running.
**```2**

**Please complete the following information:**
* OS: NixOS 21.11
* gdbgui version (`gdbgui -v`): 0.14.0.2
* gdb version (`gdb -v`): GNU Arm Embedded Toolchain 10.3-2021.10
* browser [e.g. chrome, safari]: Firefox 97
* python packages (`pip freeze`): Uh, not quite sure how to export this, installed via nix and there's a python mismatch between gdbgui and gdb (3.9 for gdbgui and 2.7 for arm-none-eabi-gdb). Will put more effort in if it's relevant.

**Additional context**
If I manually enter `continue`, I can then use the pause button correctly. However gdbgui still seems to be confused by it, and spits out errors even as it works correctly.

There are two workarounds for the correct behaviour:
- Manually enter `continue` -> pause works
- Use GUI continue -> manually enter `interrupt`

Breakpoints and all other behaviour seems to work correctly, I haven't found any issues with them.

[duaneellissd]

I can confirm this issue. I am using a RISCV target and have the same issue.