(Post 0.2 if anyone wondered...)
I've been thinking a bit about what should happen when GDB connects & disconnects to OpenOCD and my conclusion is: nothing. Nothing should happen. Just like connecting/disconnecting a telnet session. We may want to keep some of the existing behavior or add connection events, but it should be possible not to touch the target upon GDB connect. The user should be able to connect to OpenOCD via GDB and issue a monitor sequence to do whatever he deems necessary. The problem is that GDB will assume that the target is in the halted state and query for registers. I'd like to see a model where OpenOCD allows a connect and enters a state where it returns dummy values for register queries(this happens today to an extent). A faux halted state. The next command will either be a stepi or continue. What happens after connect depends on whether the target is in the halted or running state(GDB believes the target is in the halted state): - halted: continue resumes target. stepi does *not* resume the target, but returns immediately syncing up GDB & the target to the halted stated. Register queries now return the correct values. - running: continue waits for target to halt. stepi halts target. The typical connect script will then look like: target remote localhost:3333 # target is halted or running, doesn't matter monitor reset init stepi # this is a faux stepi where GDB is simply synced up to the target -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
