public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@codesourcery.com>
To: Thiago Jung Bauermann <bauerman@br.ibm.com>
Cc: Vladimir Prus <vladimir@codesourcery.com>,  gdb@sources.redhat.com
Subject: Re: Keeping breakpoints inserted
Date: Fri, 30 Nov 2007 23:53:00 -0000	[thread overview]
Message-ID: <m37ijzuw7z.fsf@codesourcery.com> (raw)
In-Reply-To: <1196456622.6746.169.camel@localhost.localdomain> (Thiago Jung Bauermann's message of "Fri, 30 Nov 2007 19:03:42 -0200")


Thiago Jung Bauermann <bauerman at br.ibm.com> writes:
> On Thu, 2007-11-29 at 22:24 +0300, Vladimir Prus wrote:
>> Anybody has comments on this approach?
>
> When adding and removing breakpoints, will GDB stop all threads or just
> the one under inspection?
>
> On first thought, I think that if adding a breakpoint can be done
> atomically (i.e., trap instruction is 1 word wide), then it wouldn't be
> necessary to stop other threads. Am I being too naive here? 

The Linux kernel has a facility called 'kprobes' (which is extremely
cool, BTW) that can insert breakpoint instructions into kernel code
while other processors are executing it.  This interface has been
implemented on many different architectures.  We're using it as our
model, since it does essentially what we need to do, in an even more
challenging context.  I haven't seen one where it needs to halt all
other processors while inserting the breakpoint.

On the i386, you pretty much just save the underlying instruction and
drop the trap in.  There are processor errata (AH 33 in
ftp://download.intel.com/design/mobile/SPECUPDT/31407915.pdf) that
warn against the dangers of one processor making changes in another's
code stream, but it turns out that the 'int3' instruction --- the one
used for breakpoints --- is specifically excluded from those errata;
so we're off the hook.

      parent reply	other threads:[~2007-11-30 23:53 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-29 19:24 Vladimir Prus
2007-11-30  1:25 ` Michael Snyder
2007-11-30 10:11   ` Vladimir Prus
2007-11-30 21:03 ` Thiago Jung Bauermann
2007-11-30 21:41   ` Michael Snyder
2007-12-01  0:08     ` Jim Blandy
2007-12-01  1:43       ` Michael Snyder
2007-12-01 17:52         ` Jim Blandy
2007-12-02 18:38           ` Thiago Jung Bauermann
2007-12-03 18:14             ` Jim Blandy
2007-11-30 23:53   ` Jim Blandy [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=m37ijzuw7z.fsf@codesourcery.com \
    --to=jimb@codesourcery.com \
    --cc=bauerman@br.ibm.com \
    --cc=gdb@sources.redhat.com \
    --cc=vladimir@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).