Great, but does it really work? There has been discussions about this on this list in the past. I think the conclusion was that there's no way to robustly know GDB's intentions based on the remote commands. When you do a source-level step in GDB, it may send a step command to OpenOCD. Then we can disable interrupts during the step. But it can also place a breakpoint at the next source line and send a continue command. In that case we must leave interrupts enabled. Wouldn't that mean an unpredictable difference in behaviour depending on how GDB chooses to do the step?
Note that I haven't yet looked at the patch so this may not be relevant. Regards, Andreas On Sat, Jun 18, 2011 at 4:26 PM, Peter Horn <peter.h...@bluewin.ch> wrote: > Dear all > > I'm submitting a change to the Cortex-M3 target which improves behavior of > single stepping with interrupts. > > Here's the description of the patch, hope you like it: > > > > This patch extends the cortex_m3 maskisr command by a new option 'auto'. > The 'auto' option handles interrupts during stepping in a way they are > processed but don't disturb the program flow during debugging. > > Before one had to choose to either enable or disable interrupts. The former > steps into interrupt handlers when they trigger. This disturbs the flow > during debugging, making it hard to follow some piece of code when > interrupts occur often. > > When interrupts are disabled, the flow isn't disturbed but code relying on > interrupt handlers to be processed will stop working. For example a delay > function counting the number of timer interrupts will never complete, RTOS > task switching will not occur and output I/O queues of interrupt driven I/O > will stall or overflow. > > Using the 'maskisr' command also typically requires gdb hooks to be > supplied by the user to switch interrupts off during the step and to enable > them again afterward. > > The new 'auto' option of the 'maskisr' command solves the above > problems. When set, the step command allows pending interrupt handlers to > be executed before the step, then the step is taken with interrupts disabled > and finally interrupts are enabled again. This way interrupt processing > stays in the background without disturbing the flow of debugging. No gdb > hooks are required. > > The 'auto' option is the default, since it's believed that handling > interrupts in this way is suitable for most users. > > The principle used for interrupt handling could probably be used for other > targets too. > > > > > > Best Regards > > Peter Horn > > _______________________________________________ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > >
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
