>> 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 ...
This white lie is a little bit problematic, however GDB will fail if we don't reply to the connect and then the second "get registers" packet, so we don't have a choice but to lie here. >> # 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". you could issue a monitor halt if you want, I wanted to illustrate the point that "stepi" will detect the target state and if the target is running, stepi will wait for it to halt, i.e. "stepi" will sync up to the target state. > Is the issue that GDB's "remote" protocol doesn't have a > very good notion of target state init? Worse than that. GUI's depending on GDB certainly don't have a notion of GDB being "halted" while the target state is unknown. The white lie is percolates all the way up to that GUI and things then "just work". Never mind changing GDB, it would take *years* to get the GUIs to follow suit. >> 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"? Hotplugging is a highly advanced feature to support robustly. JTAG doesn't really to start, but engineers have discovered that they can make a gamble on hotplugging working and getting a payoff in terms of shorter debug cycles here. -- Ø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
