This is the mail archive of the
mailing list for the GDB project.
Re: Porting gdb to Cyclops64
- From: Michael Snyder <msnyder at vmware dot com>
- To: Brian Heilig <bheilig at etinternational dot com>
- Cc: "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Fri, 30 Jul 2010 10:26:08 -0700
- Subject: Re: Porting gdb to Cyclops64
- References: <1280510022.1560.20.camel@random>
Brian Heilig wrote:
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?
Yes, see "set scheduler-locking".