> >Is it ready in your opinion? > Yes. I've been using and tweaking it for about 3 weeks. The other day I stopped making changes so as not to introduce a bug in the 11th hour (like my last simple patch). I'll let you know if I find a problem, but I'm confident that the current patch improves on the original code. Don't mean to disparage that code... the fundamentals were there, but it was very rough around the edges. xscale_analyze_trace() looks like it may have evolved into a unmaintainable hack. And clearly it was never used with a trace collected in 'wrap' mode, which seems to me to be the more useful mode since it lets you examine the path of execution leading up to a breakpoint, watchpoint, or vector trap.
If anyone has suggestions on how trace functionality should work, I'd be interested, and maybe could implement it, since I've had my nose in this for a while now. Never got around to taking a look at how generic arm ETM works. One thing I've been wondering is why there's no option to read the instructions directly from target memory, as opposed to relying on a separately loaded image file. Only thing I could think of is that the memory mapping may have changed in between collecting the trace and running the analysis (with some work, this issue can be addressed). Also annoyed that trace is always disabled on a debug break. Don't see why it can't remain enabled in 'wrap' mode. I haven't seen anything in the manual that suggests it incurs a run-time performance penalty. Thanks, Mike ---- _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
