On 02.05.2011 21:57, Jie Zhang wrote:The advantage of this approach is (amongst many other things) that >> attaching to the target does *nothing*. Via "monitor" commands, you can >> easily manipulate the target, e.g. issuing a "monitor halt". > I would say that this is confusing for a new user, like me, since it's > different to the normal usage model of GDB. For example, when GDB > attaches to a user application, it's expected that the application > will be stopped. Usually GDB starts the executable itself on the development pc and halts at main on it's own, and does not use a JTAG interface to connect to an embedded target.
In the embedded world it's quite common to attach to a running target and not halt the CPU or load the executable and stop at main, as it might be running from flash memory. When attaching to such a target it is not always possible (or nor wanted) to stop the target right away, as you may not want to interfere normal operation and just break into the target when a special HW breakpoint ot exception is hit. So I don't like the idea of automatically halting the target to satisfy GDB's needs / expectations. > What are the other advantages? The main advantage of omitting a default halt is the flexibility gain, as you are completely free on how to use openOCD to attach to your target. There is a way via scripting to get your so-called default GDB expectations, so both worlds are working with the current openOCD implementation. > If they are important, we can consider > changing GDB not to expect target halted when it connects to OpenOCD. I don't think that this change will make the GDB developers happy. Probably throwing an error from openOCD, when a register read request is received while the target is running might be a better idea, but I don't know if the GDB protocol allows this. Regards, Michael _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
