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

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?

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?

Regards,
Brian


  reply	other threads:[~2010-07-30 20:28 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 [this message]
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=1280521733.1560.44.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).