> When I found the bug > - my target was running > - the OpenOCD was running > - I realized that my application was locked, i.e. it must have crashed > somewhere, or entered some infinite loop > - I wanted to know where my application was, and possibly examine some data, > registers etc. > > In that case, there's absolutely no reason why starting GDB and connecting to > the OpenOCD should result in stale/bogus data being presented to the user. > The halt might take a while (~1s with jtag_speed 1400), but the target can > easily enter debug state, and by the time it is halted we have reliable data. > >> Do you specifically mean that the target should be halted, if possible, >> before replying to the register packet? > > Well, that's what GDB expects, isn't it? Upon connection, GDB believes the > target is halted, and queries its current state (e.g. 'g' packet).
That's right: the GDB model is broken here. It doesn't really support the concept of *attaching* to a target, which we need here. If GDB does support this, the by all means, prove me wrong by telling me how :-) GDB wants to attach to the target and have the target in the halted state. w/e.g. Visual C++ debugger, when one attaches to a process, that process continues to run until halted. Same thing would be nice w/GDB. > >> There are a couple of things that need to line up just right: >> >> - we need to allow GDB connections to dead or unresponsive targets. This >> is to allow users to have monitor commands in the GDB init script to set >> things up. >> - we need to respond immediately to the connect, or we get weird error >> messages that are pretty much impossible to deduce anything from, it >> just looks like OpenOCD or GDB is broken) > > You forgot: > > - we must not reply with bogus/stale data. if we absolutely must reply with > bogus data we should at least inform the user... That is is imperative, does make a patch that solves all the problems materialize out of thin air. > >> You didn't include a -d3 log, so I don't know much about what happened >> in your debug session. > > I've already sent the -d3 log last night: > https://lists.berlios.de/pipermail/openocd-development/2008-July/002756.html > >> Perhaps we can get rid of the white lie upon connect, but for >> now it seems like the best option. >> >> Perhaps waiting 500ms for the halted state will do the trick? > > Thanks a lot, looks like that worked. Do you know how much time we have here? Nope. > Would it be possible to keep GDB going with the empty reply packets we send > in keep_alive? The keep_alive() trick only works when the target is in the running state, or executing a monitor command. Actually... perhaps you have the solution right there. Add a "monitor wait_halt" at the beginning of your GDB init script. This will wait upto 5 seconds and afterwards the PC should be correct. A robust approach would then be: - we do nothing when connecting to the target. We don't even issue a halt. Remove the current "target_halt" even. - lie to the GDB register packet that GDB insists on sending upon startup and return garbage. - require the user to add in GDB commands to halt the target. "monitor reset init", "monitor halt", "stepi", "monitor wait_halt", etc. Note that monitor halt is synchronous. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
