On Sunday 17 January 2010, Øyvind Harboe wrote: > I'm not sure we have a regression here.
Against 0.3.1 it seems we don't have one... Against 0.2.0 it looks like we do (did)... (If I understand correctly.) > A regression test should minimally include: > > 1. test sequence > > 2. expected result > > If we agree that both are according to OpenOCD documentation/support, > and it fails on one version and not the other, then we have a regression. Actually, behavior change suffices ... so long as that change isn't a bugfix, or documented as a new behavior (e.g. new feature). Unfortunately not every behavior is documented clearly enough to use the documentation to make a "bugfix?" call. Changes in undocumented (or badly documented) behaviors are troublesome in two ways: first the docs; second that anyone relied on the behavior. That's a real nightmare when anyone has committed to binary interfaces, unless they're well versioned, since they're pretty much stuck forever with being backwards bug-compatible. Protocol interfaces are one flavor of binary interface. > Could you provide 1+2? (I could perhaps extract that information from > the logs, but > I want to hear more about what you intended and what you expected to see.) > > > > A few comments relating to the gdb sync feature and openocd/gdb > making fewer assumptions about the target: > > Targets and interfaces will have some state when OpenOCD is not > running and/or the target is not connected. Obviously openocd should not try > to make much in the way of assumptions about disconnected targets. > > I made a change where I made OpenOCD do *nothing* upon > connecting w/GDB, not even query the target. > > This solves a raft of issues w.r.t. configuring what should happen upon > connect and how you put the target into a particular state. > > You simply put whatever you want into > the gdb init sequence, no config options, fancy events, etc. Previously > openocd would issue a halt upon gdb connect, whether or not that > was something that the user needed or wanted to happen. Most likely > the user was unaware of it. > > So, typically when connecting with GDB and loading you should do > something like: > > target remote xxx > # the target is not affected or queried by a gdb connnect. Dummy values are > # returned and a white lie takes place w.r.t. that the target is halted. That "white lie" may be problematic. However, I've only looked a bit at the GDB remote protocol, and I suspect that it's causing some issues. It doesn't *require* clean target identification, as just one example ... > # OpenOCD allows gdb to be in the halted state and have the > # target running or halted. You can resume openocd when the target > # is either running or halted, as the openocd GDB server will > # sync up to the target upon a stepi/continue. > # > # halt can *fail* before monitor reset init, so fortunally > # we have *complete* control over the gdb init sequence now > monitor reset init This reset step is obviously not required in all cases. I agree that it should not be *automagically* performed, even the weaker "monitor halt" equivalent which was happening prior to the "gdb sync" patch. > load > # the gdb sync flag is set upon GDB connect, > # stepi will not step here, but cause a fresh set of registers > # to be fetched into gdb > stepi > > > Example #2: > > I want to get fancy and try to hotplug to a target and halt it: I don't think I'd call that "fancy". :) > # 1. start openocd > # 2. hotplug a target we want to examine > target remote xxxx > # we're now connected to the GDB server, OpenOCD has not > # talked to the target yet. GDB is "halted", but really the target > # could be running or halted, we don't know. The sync flag > # is set upon connect, so "stepi" will not stepi, but wait for the target to > be > # halted, if it isn't already and then fetch a fresh set of registers > stepi > => press ctrl - c, if we're lucky, we can now debug the hot plugged target I guess I'm puzzled why "stepi" would be used instead of some kind of real "halt". Is the issue that GDB's "remote" protocol doesn't have a very good notion of target state init? > > Now.... hotplugging *can* work on simpler CPUs, but anything reasonably > complex(Cortex-A8, XScale, etc.), naive hotplugging is *very* unlikely to > be of much use. XScale is kind of odd; it requires special magic to hotplug. In large part that is ISTR caused by its funky requirement to run with a baby debug monitor loaded into its mini-ICache. Other than that ... what do you mean by "naive"? - Dave _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
