On Wednesday 23 September 2009, Øyvind Harboe wrote: > I don't know much about the hardware trace capabilities, > but I have understood that it's effectively a trace log of > what happened.
Various kinds of events yes, like branches, data access, CPU state transitions and so on. The exact events vary between chips; and there's a *LOT* of attention spent on how to limit the events that get recorded. Without such pre-filtering, there'd be too much data to use... > Wouldn't it be neat(even useful??) if it was possible to step > through the last N instructions? Should be pretty trivial to configure: save *everything* into a circular buffer, then dump it and ignore all but the last N instruction events. > Here is what I have in mind: > > - Issue a "monitor trace 100" => we want to step through the > last 100 instructions. > > - You can now issue stepi to step through each of the last > 100 instructions. The way it's set up now is that you set things up, then collect the data, and finally dump it (or save it). There's no GDB integration. And I don't actually know for sure that it all works, anyway. Yet! :) There are quite a few commercial products which support tracing; there's stuff to be learned by seeing what they do. I don't know that any integrate with their QEMU analogues though ... the ones I know about seem to focus on simulation for early development, or for providing cycle-accurate timings in advance of tracing cycle counts on the actual hardware. For performance work, that is. - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
