> Could you provide a list of what order you give GDB/OpenOCD commands and > which GDB-Remote commands/responses you see?
I'm remote from my test hardware at the moment - I'll try to do that as soon as possible > The way I did it in the RTOS’s was that if the current thread was set to 0 > or 1 then it returned the current running context (i.e. the true register > values). This seems to avoid the problem you’re having. I had noticed that, and queried whether the test should be 1 or -1 (I thought it should be -1, and submitted a patch to change it). I have a thread whose ID is 1, and the wrong thing was happening. My code seems to correctly differentiate between current/stacked threads, and return the correct register values for them. > · You may need to fix the GDB bug described in > http://sourceware.org/bugzilla/show_bug.cgi?id=12648 I don't think I'm running afoul of that, since you mention Eclipse and I'm using command-line GDB. It could be a problem, though, and I'll look into it. > · Generally you will want to make your OpenOCD script blank the > device memory so that the RTOS awareness does not read old, invalid thread > information I think the issue I saw was that gdb requested the current thread (qC) before the RTOS thread update was called. Because I had no explicit clear of the RTOS structure after reset (irrespective of the state of my target's RAM) the current thread that was returned was the same as the last update prior to target reset. Thanks for the feedback Alan _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
