public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Brian Heilig <bheilig@etinternational.com>
To: gdb@sourceware.org
Subject: Porting gdb to Cyclops64
Date: Fri, 30 Jul 2010 17:13:00 -0000	[thread overview]
Message-ID: <1280510022.1560.20.camel@random> (raw)

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


             reply	other threads:[~2010-07-30 17:13 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-30 17:13 Brian Heilig [this message]
2010-07-30 17:26 ` Michael Snyder
2010-07-30 18:53   ` Brian Heilig
2010-07-30 18:57     ` Michael Snyder
2010-07-30 20:28       ` Brian Heilig
2010-07-30 22:54         ` Michael Snyder
2010-07-30 23:18         ` Pedro Alves
2010-08-02 13:25           ` Brian Heilig
2010-08-02 13:35             ` Pedro Alves
2010-08-03 16:52               ` Brian Heilig
2010-08-05 13:56               ` Brian Heilig
2010-08-05 14:19                 ` Pedro Alves
2010-08-06 18:39                   ` Problems with non-stop - " Brian Heilig
2010-08-30 19:44                   ` Cyclops64 Multi-Process Brian Heilig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1280510022.1560.20.camel@random \
    --to=bheilig@etinternational.com \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).