From: Mathias K. <ke...@fr...> - 2011-11-23 05:16:57
|
Hello, On 23.11.2011 06:08, Peter Stuge wrote: > James Zhao wrote: >> So it would seems that when gdb_new_connection is invoked, there is not >> check if device is halted or not. >> And this become a problem when trying to get register since the device >> needed to be halted first. >> Is there a good place in the code to add a check for device halt, when >> gdb_new_connection is called? > > In principle I agree with the proposed patchset, but in practise I'm > not sure where it should go. > > When I make gdb attach to OpenOCD I *always* want gdb to have control > over the target CPU. This isn't the case if the CPU is running, and I > must fiddle with continue and Ctrl-C to get into a reliable > synchronised state. Lame! > > Halting on gdb connect is indeed one way to change that - but I'm not > sure it's the right way. Another way would be to make gdb always > issue a halt. I'm not sure what semantics gdb uses for remotes. This is already done with the gdb monitor command. Simple use "monitor reset halt" in your gdb session to stop the target. You can also burn the flash with the monitor command. I think it's not a good idea to halt the target on every new gdb connection. Regards, Mathias |