Re: Porting gdb to Cyclops64

[Michael Snyder <msnyder@vmware.com>]

Brian Heilig wrote:
> Dear list,
> 
> My name is Brian Heilig and I am porting gdb 7.1-90 to the Cyclops64
> architecture. Cyclops64 has 80 cores and each core has 2 thread units
> for a total of 160 threads units, all running in parallel. Each thread
> unit executes the same code and can access shared memory or its own
> thread memory (http://en.wikipedia.org/wiki/SPMD). A traditional thread
> model is also supported where SPMD threads can spawn other threads.
> 
> I have integrated a gdb server into our kernel and integrated the target
> architecture into the gdb client. Right now I can remote debug a program
> on the target but it doesn't handle multiple threads well.
> 
> When multiple threads are stopped at a breakpoint (or stopped for some
> other reason) I should be able to step through the current thread. When
> I do gdb is commanding the target to step the current thread and
> continue all others like "$vCont;s:1;c".
> 
> The plan is to step the current thread and leave all others stopped
> until I tell it to continue. If multiple threads stop at a breakpoint
> then the target will queue these events. When the target is told to
> continue it will notify the client that the next thread has stopped at a
> breakpoint. If the user desires they can switch to another thread that
> is stopped and step it.
> 
> Does gdb support the operation 'step the current thread and leave all
> other threads stopped'? Is there some mode or variable I need to set in
> the target architecture description to enable this? What is gdb's
> behavior now for multi-core architectures?
> 
> Thanks,
> Brian

Yes, see "set scheduler-locking".

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