From: Brian Heilig <bheilig@etinternational.com>
To: gdb@sourceware.org
Subject: Re: Porting gdb to Cyclops64
Date: Thu, 05 Aug 2010 13:56:00 -0000 [thread overview]
Message-ID: <1281016608.1560.79.camel@random> (raw)
In-Reply-To: <201008021435.16106.pedro@codesourcery.com>
Dear list,
In my previous message I described a problem I encountered while
stepping a multi-threaded program. Here is a general description of
what's happening.
All threads execute in parallel (on their own core) on the Cyclops64
chip. I implemented a queue on the gdb server to serialize events. This
makes Cyclops64 look like a cooperatively scheduled architecture to gdb
in stop mode.
While single stepping a single thread (let's call it thread 5) gdb
decided to set a breakpoint at some address and continue all threads.
All threads hit this internal breakpoint including thread 5. The
breakpoint events for threads 1-4 are reported and ignored by gdb (gdb
knows it doesn't care about these threads). Then thread 5 is reported
and gdb removes the breakpoint. However the event for threads 6-n are
still in the queue. The next time the user continues these events are
reported. Since gdb removed the internal breakpoint it assumes these
events must be caused by something else and doesn't filter them out.
Is there anything I can do about this? Is there a facility to set a
breakpoint for a single thread and filter them on the server? Or is this
just a consequence of gdb not knowing how to deal with an SPMD
architecture yet?
Thank You,
Brian
next prev parent reply other threads:[~2010-08-05 13:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-30 17:13 Brian Heilig
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 [this message]
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=1281016608.1560.79.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