grisp
Debugging with OpenOCD/GDB is not working.
When trying to debug with OpenOCD and GDB, the debugger is not working properly after breaking.
First Issue
When setting a breakpoint (hardware or software) and continuing the execution GDB break correctly but then stepi do not advance the code pointer. This happens even when masking the interruptions.
Second Issue
When setting a breakpoint at a give line number in some code compiled with debug info and without optimization (-g -O0) GDB set the breakpoint to the beginning of the function regardless of the specified line number.
Example
Host
Ubuntu 17.04 64-bit Intel® Core™ i7-4770K CPU @ 3.50GHz × 8
GDB Console
GNU gdb (GDB) 7.12
Copyright (C) 2016 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-rtems4.12".
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 testproject/erts-9.2/bin/beam...done.
0x00400144 in ?? ()
force hard breakpoints
$1 = "Resetting target"
Reset, run bootloader and stop system
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00400144 msp: 0x20401148
target halted due to watchpoint, current mode: Thread
xPSR: 0x21000000 pc: 0x0049ab3c psp: 0x732240c8
breakpoint set at 0x70000144
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x70000144 psp: 0x73224140
Loading section .start, size 0x3f8 lma 0x70000000
Loading section .text, size 0x31f394 lma 0x70000400
Loading section .init, size 0xc lma 0x7031f794
Loading section .fini, size 0xc lma 0x7031f7a0
Loading section .rodata, size 0x2106b8 lma 0x7031f7c0
Loading section .ARM.exidx, size 0x8 lma 0x7052fe78
Loading section .eh_frame, size 0x4 lma 0x7052fe80
Loading section .init_array, size 0x4 lma 0x7052fe84
Loading section .fini_array, size 0x4 lma 0x7052fe88
Loading section .rtemsroset, size 0x878 lma 0x7052fe8c
Loading section .data, size 0x1ed8c lma 0x70530708
Loading section .rtemsrwset, size 0x3fd4 lma 0x7054f498
Start address 0x70000144, load size 5583944
Transfer rate: 126 KB/sec, 15685 bytes/write.
(gdb) set remote hardware-breakpoint-limit 8
(gdb) set remote hardware-watchpoint-limit 4
(gdb) hbreak ethr_thr_create:405
Hardware assisted breakpoint 1 at 0x702e80ea: file pthread/ethread.c, line 320.
(gdb) continue
Continuing.
Breakpoint 1, ethr_thr_create (tid=0x7055ff30 <sig_dispatcher_tid>, func=0x7013fe39 <signal_dispatcher_thread_func>, arg=0x0, opts=0x7061b034) at pthread/ethread.c:320
320 : -1 /* Use system default */);
(gdb) monitor cortex_m maskisr on
cortex_m interrupt mask on
(gdb) print $pc
$2 = (void (*)()) 0x702e80ea <ethr_thr_create+14>
(gdb) stepi
Breakpoint 1, ethr_thr_create (tid=0x7055ff30 <sig_dispatcher_tid>, func=0x7013fe39 <signal_dispatcher_thread_func>, arg=0x0, opts=0x7061b034) at pthread/ethread.c:320
320 : -1 /* Use system default */);
(gdb) print $pc
$3 = (void (*)()) 0x702e80ea <ethr_thr_create+14>
(gdb) stepi
Breakpoint 1, ethr_thr_create (tid=0x7055ff30 <sig_dispatcher_tid>, func=0x7013fe39 <signal_dispatcher_thread_func>, arg=0x0, opts=0x7061b034) at pthread/ethread.c:320
320 : -1 /* Use system default */);
(gdb) print $pc
$4 = (void (*)()) 0x702e80ea <ethr_thr_create+14>
(gdb) continue
Continuing.
Breakpoint 1, ethr_thr_create (tid=0x7055ff30 <sig_dispatcher_tid>, func=0x7013fe39 <signal_dispatcher_thread_func>, arg=0x0, opts=0x7061b034) at pthread/ethread.c:320
320 : -1 /* Use system default */);
(gdb) print $pc
$5 = (void (*)()) 0x702e80ea <ethr_thr_create+14>
(gdb) next
Breakpoint 1, ethr_thr_create (tid=0x7055ff30 <sig_dispatcher_tid>, func=0x7013fe39 <signal_dispatcher_thread_func>, arg=0x0, opts=0x7061b034) at pthread/ethread.c:320
320 : -1 /* Use system default */);
(gdb) print $pc
$6 = (void (*)()) 0x702e80ea <ethr_thr_create+14>
(gdb)
OpenOCD Console
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : FTDI SWD mode enabled
adapter speed: 1800 kHz
cortex_m reset_config sysresetreq
Info : flash bank command
srst_only separate srst_gates_jtag srst_open_drain connect_deassert_srst
adapter speed: 6000 kHz
basic initialization done
reset_and_run_bootloader
Info : clock speed 6000 kHz
Info : SWD DPIDR 0x0bd11477
Warn : Silicon bug: single stepping will enter pending exception handler!
Info : atsame70q21.cpu: hardware has 8 breakpoints, 4 watchpoints
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00400144 msp: 0x20401148
Info : accepting 'gdb' connection on tcp/3333
Info : device id = 0xa1020e00
force hard breakpoints
Reset, run bootloader and stop system
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00400144 msp: 0x20401148
target halted due to watchpoint, current mode: Thread
xPSR: 0x21000000 pc: 0x0049ab3c psp: 0x732240c8
breakpoint set at 0x70000144
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x70000144 psp: 0x73224140
cortex_m interrupt mask on
The problem really is nasty. Here is, what I found out for topic 1:
when you either do a step or set a breakpoint, openOCD will write a "breakpoint opcode" to the assembly instruction location you want to stop the processor. When the processor fetches this instruction, it stops and openOCD (and gdb) take control again and writes the original assembly instruction to memory. Then, the processor should be able to execute the original code, when you make the next step...
But: If the instruction cache is enabled, the previously fetched breakpoint instruction is still there and will be executed again. Note that openOCD has written the original instruction to memory, but not into the instruction cache.
If you perform the following command in gdb:
monitor mww 0xE000EF50 0x0
you should be able to proceed from your breakpoint, at least to single step once... But this is surely not the definitive way to handle that.
Another way might be to add a "hook-stop" to gdb:
define hook-stop monitor mww 0xE000EF50 0x0 end
and add these lines to your gdb init script "start-gdb.
This is not yet a final solution and works far from perfect, so I a still busy investigating further...
Regarding your second topic:
is "hbreak ethr_thr_create:405" actually a valid syntax to set a breakpoint at line 405?
See: (gdb) l led_timer 52 53 static rtems_id led_timer_id = RTEMS_INVALID_ID; 54 55 static void 56 led_timer(rtems_id timer, void *arg) 57 { 58 rtems_status_code sc; 59 static uint8_t state = 0x1; 60 bool r, g, b; 61 (gdb) l 62 (void)arg; 63 64 sc = rtems_timer_reset(timer); 65 assert(sc == RTEMS_SUCCESSFUL); 66 67 ++state; 68 if (state > 0x7) { 69 state = 0x0; 70 } 71 (gdb) b 67 Breakpoint 3 at 0x700004e4: file init.c, line 67. (gdb) b led_timer:64 Breakpoint 4 at 0x700004ca: file init.c, line 64. (gdb) b led_timer:69 Note: breakpoint 4 also set at pc 0x700004ca. Breakpoint 5 at 0x700004ca: file init.c, line 64. (gdb) info b Num Type Disp Enb Address What 3 breakpoint keep y 0x700004e4 in led_timer at init.c:67 4 breakpoint keep y 0x700004ca in led_timer at init.c:64 5 breakpoint keep y 0x700004ca in led_timer at init.c:64
Obviously, breakpoint 4 is set to the first code line of function led_timer, and breakpoint 5 is set to the same line...
So I don't think you can set a breakpoint on a specific line in a function, you can only set it to a line in a file...
Hi,
I had a discussion on the openocd user's list:
and it seems debugging and cache usage is .... not yet properly supported for the cortex-m. So we will have to discuss, how to proceed in this matter...
https://sourceforge.net/p/openocd/mailman/openocd-user/thread/317f059d-05aa-d0ef-a3bc-05185cabbb5b%40embedded-brains.de/#msg36233116
The solution I proposed as a work around doesn't seem to work reliably either :-(