6

I am trying to debug a program using arm-none-eabi-gdb and step through it. There is an interrupt, USB0_Handler, which I do not want to step into while stepping the program. To achieve this, I tried to use skip, but it didn't work, even if I try to skip the function or skip the entire file (containing the interrupt). I am using openocd to achieve the remote debugging on the tm4c123gh6pm.

I have reached a point where I don't know if I should define myself a gdb function or I am missing a point. Here is the output of my terminal : 

(gdb) info skip
Num     Type           Enb What
1       function       y   USB0_Handler
(gdb) c
Continuing.

Breakpoint 2, relayTask () at ./relay.c:191
191         nextTime = rtcGetTimeIn(DEFAULT_REFRESH_RATE);
(gdb) n
USB0_Handler () at ./UsbConfig.c:326
326 {
(gdb) n
332     ui32Status = MAP_USBIntStatusControl(USB0_BASE);
(gdb) n
337     USBDeviceIntHandlerInternal(0, ui32Status);
(gdb) n
338 }
(gdb) n  #returning at the top of USB0_Handler
326 {
adriel
  • 61
  • 1
  • 2
  • 2
    You don't **step** into the handler, but it just happens to occur while you step the code. – too honest for this site Jun 07 '16 at 00:27
  • You could try the *finish* command to step out of the interrupt handler. – markgz Jun 07 '16 at 00:35
  • I'm not sure gdb has a nice way to do this. If there is nothing in `UsbConfig.c` that you need to debug, perhaps one workaround would be to ensure that it is compiled without debugging info (ie, no `-g` on the compiler command line). – kaylum Jun 07 '16 at 00:57
  • the _finish_ command actually didn't work. I recently modified my Makefile to add a specific rule for `UsbConfig.c` (without -g or -ggdb), but I still fall into `USB0_Handler` while debugging (with the new build) – adriel Jun 07 '16 at 02:46
  • see this: https://stackoverflow.com/a/73332095/6318003 – Changbin Du Aug 12 '22 at 10:42

1 Answers1

1

When an interrupt is triggered while stepping, GDB usually stops because the step ended in a place it didn't expect.

Interrupt handlers are generally hard to deal with from a debugger point of view because they are executed in a new context: the stack frames are changed and unless GDB recognizes a particular pattern in the frame it won't be able to compute a complete stack trace (i.e. the interrupt handler frames + your regular program stack trace before the interrupt.)

The simplest way to get you out of the interrupt handler is to plant a breakpoint on the last line of the function, resume and continue stepping. Someone suggested to use the finish command but it may fail depending on again the quality of the stack trace.

Thanks to GDB scriptability (in python for instance) it may be possible to automate that by checking the PC and if PC is on the isr address in irq vector, fetch the return address, plant a temporary breakpoint and resume.

Christophe Augier
  • 565
  • 3
  • 9