Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org
Cc: "Pierre Muller" <muller@ics.u-strasbg.fr>
Subject: Re: [RFC] win32-nat.c 'set new-console' and interruption
Date: Mon, 23 Jun 2008 17:00:00 -0000	[thread overview]
Message-ID: <200806231541.26276.pedro@codesourcery.com> (raw)
In-Reply-To: <001001c8d53c$a773fe50$f65bfaf0$@u-strasbg.fr>

A Monday 23 June 2008 15:23:06, Pierre Muller wrote:

> I have a proposal to remove that possible race condition:
> The exception record has a field that contains the exception
> address, if I test that there is no GDB inserted breakpoint at
> that location before converting the TARGET_SIGNAL_TRAP
> into a TARGET_SIGNAL_INT, it should fix most problems, no?
>
>   The one case that it would still not catch would be
> a 'int 3' instruction that is in the debuggee code from the start
> but other than at startup, such instructions are quite unlikely, no?
>

IIRC, DebugBreakProcess injects a thread in the debuggee and
always breaks at the same address / in the same function -- I don't
know if there's a hardcoded 0xcc at the break address you
could check, or if the exception is generated programatically,
but at least you could conditionalize on the function name (if there's
no hardcoded break, you still can't distiguish by name only a user
break placed in that special break function)

Another option is to use SuspendThread on all threads to stop
the process, which is what I believe Visual Studio uses.
gdbserver has that implemented for systems that don't have
DebugBreakProcess.

-- 
Pedro Alves


  reply	other threads:[~2008-06-23 14:41 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-21 17:05 Pierre Muller
2008-06-21 18:37 ` Christopher Faylor
2008-06-22  3:17   ` Daniel Jacobowitz
2008-06-22  3:18     ` Corinna Vinschen
2008-06-23  1:04       ` Christopher Faylor
2008-06-23  1:10         ` Corinna Vinschen
2008-06-23  7:40         ` Pierre Muller
2008-06-23 12:00           ` Christopher Faylor
2008-06-23 16:05             ` Pierre Muller
2008-06-23 17:00               ` Pedro Alves [this message]
2008-06-23 17:25                 ` Pierre Muller
2008-06-23 18:03                 ` Christopher Faylor
2008-06-23 19:24                   ` Pedro Alves
2008-06-23 20:33                     ` Pierre Muller
2008-06-23 21:06                       ` Joel Brobecker
2008-06-24  6:33                         ` Christopher Faylor
2008-06-24 13:36                           ` [RFC-v3] " Pierre Muller
2008-06-24  2:33                     ` [RFC] " Christopher Faylor
2008-06-24 13:54                       ` Pedro Alves
2008-06-24 18:29                         ` Christopher Faylor
2008-06-22  9:00     ` Christopher Faylor
2008-06-23  8:52   ` [RFC v2] " Pierre Muller

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=200806231541.26276.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --cc=muller@ics.u-strasbg.fr \
    /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