Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: "Paul Koning" <Paul_Koning@Dell.com>
To: "Pedro Alves" <pedro@codesourcery.com>, 	<gdb@sourceware.org>
Subject: RE: Two threads hitting the same break
Date: Thu, 18 Mar 2010 20:09:00 -0000	[thread overview]
Message-ID: <D8CEBB6AE9D43848BD2220619A43F326538E31@M31.equallogic.com> (raw)
In-Reply-To: <D8CEBB6AE9D43848BD2220619A43F326538E2F@M31.equallogic.com>

Never mind, I misread a test.  It looks like the Linux code does behave
the way I want.  Sorry for the confusion, and thanks for the help.

	paul

> -----Original Message-----
> From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On
> Behalf Of Paul Koning
> Sent: Thursday, March 18, 2010 4:02 PM
> To: Pedro Alves; gdb@sourceware.org
> Subject: RE: Two threads hitting the same break
> 
> Thanks.
> 
> I'm not sure about using that model -- it doesn't behave in an
> intuitive
> fashion.
> 
> If I have two threads that hit the same break at the same time, I
would
> expect to see both breaks.  The Linux code tosses one of them.  Given
> how it picks threads to report, the next time the two threads hit a
> break, the one that wasn't reported the first time will be reported
> this
> time.  But the net result is that I only see a portion of the breaks
--
> half of them if there are two threads.
> 
> Consider a test case of the form
>   - print something
>   - wait a bit
>   - repeat
> 
> If I set a break in that loop and keep hitting continue, I see one
> break
> per pass through the loop even if there are two threads executing this
> loop.  I'm not sure why the Linux folks chose to make it work that
way;
> I'm not sure I want to copy that behavior.
> 
> Then again, doing something more obvious might be hard...
> 
> 	paul
> 
> > -----Original Message-----
> > From: Pedro Alves [mailto:pedro@codesourcery.com]
> > Sent: Thursday, March 18, 2010 3:36 PM
> > To: gdb@sourceware.org
> > Cc: Paul Koning
> > Subject: Re: Two threads hitting the same break
> >
> > On Thursday 18 March 2010 19:26:52, Paul Koning wrote:
> > > I think I've seen discussion of this sort of issue, possibly in
the
> > > code, but I'm not having much luck finding it.  Any suggestions
for
> > the
> > > right way to handle this?
> >
> > See linux-nat.c:cancel_breakpoint.
> >
> > --
> > Pedro Alves


      reply	other threads:[~2010-03-18 20:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-18 19:27 Paul Koning
2010-03-18 19:36 ` Pedro Alves
2010-03-18 20:02   ` Paul Koning
2010-03-18 20:09     ` Paul Koning [this message]

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=D8CEBB6AE9D43848BD2220619A43F326538E31@M31.equallogic.com \
    --to=paul_koning@dell.com \
    --cc=gdb@sourceware.org \
    --cc=pedro@codesourcery.com \
    /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