I'm not sure we have a regression here. 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. 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. # 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 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: # 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 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. -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
