This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Porting gdb to Cyclops64


Brian Heilig wrote:
On Fri, 2010-07-30 at 10:26 -0700, Michael Snyder wrote:
Brian Heilig wrote:
Does gdb support the operation 'step the current thread and leave all
other threads stopped'?
Yes, see "set scheduler-locking".

http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gdb/thread-stops.html


Thank you.


When I attach to my remote target, if the target is running (not stopped
at a breakpoint) gdb currently doesn't know it and presents the gdb
prompt as if the inferior were stopped. Clearly I've not implemented the
protocol correctly in this case.

Should I stop the inferior when the client is attached? Or should I send
a response from my target that will indicate to gdb that it is currently
running?

The default mode is synchronous debugging, which means that any time you are looking at the gdb prompt, the target is stopped.

It would probably be easiest to implement that first and get it working,
before attempting asynchronous mode.

So yes, attaching with gdb should stop the target.

Is there a reference for the most recent remote protocol? I'm sure I've
only implemented a small subset of the protocol, and that probably isn't
%100 correct.

You certainly don't have to implement everything all at once.


Try this for a reference:


http://sourceware.org/gdb/current/onlinedocs/gdb/Remote-Protocol.html#Remote-Protocol




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]