public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Michael Snyder <msnyder@vmware.com>
To: Brian Heilig <bheilig@etinternational.com>
Cc: "gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: Porting gdb to Cyclops64
Date: Fri, 30 Jul 2010 22:54:00 -0000	[thread overview]
Message-ID: <4C535831.8090000@vmware.com> (raw)
In-Reply-To: <1280521733.1560.44.camel@random>

Brian Heilig wrote:
> On Fri, 2010-07-30 at 11:57 -0700, Michael Snyder wrote:
>> 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.
> 
> Thanks again Michael.
> 
> Since all threads execute in parallel, more than one thread can hit a
> breakpoint. In stop mode I should stop all threads when the first thread
> hits a breakpoint. While stopping all threads other threads might hit a
> breakpoint. My intention is to queue these "events" and report them in
> sequential order to gdb. So that, in stop mode, when gdb tells the
> target to continue it will actually dequeue the next event. If there are
> no events then it will continue. Does this sound correct?

That's very similar to the way it works on native Linux.
Not because of true parallelism, but because we can't really
stop all the threads and start them again simultaneously.

> I guess I will have to implement non-stop mode as well since many
> threads can hit a breakpoint. It would be very inconvenient for my user
> to have to continue each thread individually. In this case I will not
> queue events but rather just send them to gdb and let gdb sort them out.
> Is this correct as well?

I'm not sure -- maybe someone else will care to jump in.

  reply	other threads:[~2010-07-30 22:54 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 [this message]
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=4C535831.8090000@vmware.com \
    --to=msnyder@vmware.com \
    --cc=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).