Resending, Cc to the list got lost somewhere... On Sat, Jun 18, 2011 at 8:27 PM, Andreas Fritiofson < andreas.fritiof...@gmail.com> wrote:
> > > On Sat, Jun 18, 2011 at 6:38 PM, Peter Horn <peter.h...@bluewin.ch> wrote: > >> Hi Andreas >> >> Am 18.06.2011 17:32, schrieb Andreas Fritiofson: >> >> Great, but does it really work? >>> >> >> I've tested it with a simple test program containing a main loop and a >> SysTick_Handler(). >> >> I've also tested it with a real application in which UART RX interrupts >> happen at least once per second (heart beat message of a slave processor >> coming in). Without the patch, I wasn't able to do stepping, because each >> step ran into the UART handler. Disabling the interrupts led to blocking >> because UART output queues overflowed, nothing was received anymore and no >> RTOS task switching happened. >> > > Received data will probably be lost even with your patch, unless you step > often enough. > > >> With the patch I can do useful work with the debugger again. >> >> >> >> 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. >>> >> >> That's true. You can see what GDB does when you read openocds debug >> output messages. My comments below are found by observation. >> >> >> >> 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. >>> >> >> Step commands are issued by GDB when it doesn't know for sure that the >> next assembly instruction won't branch. It steps as many times as >> required until an address is reached which doesn't belong to the current >> line. Exactly this will happen when a pending interrupt triggers: A >> branch to the handler and voila, we're on a address that doesn't belong >> to the line we're stepping, so GDB stops. >> >> Only the step command is addressed by my patch: It first lets pending >> interrupts execute, then disables interrupts, steps over the instruction >> and finally re-enables the interrupts. >> >> > I didn't realize you wanted to _execute_ interrupt handlers during step, > just not break in them. That's rather brilliant and probably a good default > behaviour. > > >> >> But it can also place a breakpoint at the next source line and send a >>> continue command. >>> >> >> GDB uses this strategy when it steps over function call, assuming it >> will return to the next instruction after the call. This is done to >> speed up things. Instruction stepping takes some milliseconds per step. >> >> When GDB uses this method to step, interrupt handlers don't disturb >> debugging flow because the target isn't stopped before return >> from the function call. >> >> The continue command isn't changed by my patch. >> >> In that case we must leave interrupts enabled. >>> >> >> Right. Interrupts only get disabled during the step over the next >> instruction, they are enabled afterward, see above. >> >> This is exactly the problem with the GDB hooks to enable and disable the >> isr masking during stepping. They disable the interrupts in both cases >> because they act on the GDB step command, not the target step command. My >> patch acts on the target step command only. > > > The GDB hooks are meant for a different use-case. Sometimes you want to > step around and at the same time guarantee that no isr or other code will be > run behind your back. Just making sure that the debugger breaks on the > expected line may not be enough. That use-case is still available exactly as > today, with GDB hooks and maskisr on/off. Which is good. > > >> >> Wouldn't that mean an unpredictable difference in behaviour depending >>> on how GDB chooses to do the step? >>> >> >> No. In both cases pending interrupt handlers will be called and in both >> cases GDB stops on the next line. >> >> > I see. I assumed you wanted the same behaviour as the GDB hooks use-case. > > >> Note that I haven't yet looked at the patch so this may not be >>> relevant. >>> >> >> I would be glad if you can try it on a real use case. >> >> > I've briefly checked the patch now. I won't probably have time to test it > anytime soon. But basically it looks good. I guess there's no way around > requiring setting a breakpoint at the current pc to force any pending isr to > run? Also, will it make stepping significantly slower? > >
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
