Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Pierre Muller" <muller@ics.u-strasbg.fr>
To: <gdb-patches@sourceware.org>
Subject: RE: [RFA] windows-nat.c Cygwin save_context fix
Date: Mon, 21 Sep 2009 22:35:00 -0000	[thread overview]
Message-ID: <000001ca3b0b$d8310250$889306f0$@u-strasbg.fr> (raw)
In-Reply-To: <20090921222637.GC17886@ednor.casa.cgf.cx>



> -----Message d'origine-----
> De : Christopher Faylor [mailto:cgf-use-the-mailinglist-
> please@sourceware.org]
> Envoyé : Tuesday, September 22, 2009 12:27 AM
> À : gdb-patches@sourceware.org; Pierre Muller
> Objet : Re: [RFA] windows-nat.c Cygwin save_context fix
> 
> On Mon, Sep 21, 2009 at 05:14:57PM +0200, Pierre Muller wrote:
> >  Cygwin has a way to give a "fake" context for
> >an exception using a OUTPUT_DEBUG_STRING_EVENT.
> >
> >  While trying to debug some crashes inside cygwin dll,
> >I realized the the saved_context code has a problem.
> >
> >  The saved context was correctly written to the thread_info
> >struct, but later overwritten by a call to GetThreadContext.
> >
> >  After the cygwin special output_debug_string was correctly
> >converted into a context stored in saved_context.
> >  The next call to do_windows_fetch_inferior_registers
> >then copied this context to the thread_info struct,
> >set the reload_context field to zero.
> >
> >  But a later call to thread_rec() with get_context=1
> >can reset reload_context to one, if suspended field
> >is zero (this only happens if it is not the main thread).
> >
> >  My patch fixes the problem by explicitly calling
> >SuspendThread for the threaded of the saved_context
> >if suspended is still zero at that point.
> >
> >
> >Pierre Muller
> >Pascal language support maintainer for GDB
> >
> >
> >
> >2009-09-21  Pierre Muller  <muller@ics.u-strasbg.fr>
> >
> >	* src/gdb/windows-nat.c (saved_threadid): New variable.
> >	(do_windows_fetch_inferior_registers): Check for correct thread
> id
> >	and force call to SuspendThread if needed.
> >	(handle_output_debug_string): Set saved_threadid.
> 
> I REALLY hate SuspendThread and am not likely to accept a patch which
> uses it as a solution.

  I don't think that we really need to call SuspendThread,
in fact, I suspect the best would be to set suspended
to -1 as for main_threadid. I will try to check out if this also works.

> I don't really understand the scenario that you are talking about since
> I (obviously?) have no problems debugging SEGVs in cygwin.  However,

  I was trying to debug a home compiled expect 
linked to 8.5.7 tcl library, that was call abort,
and the subsequent cygwin stackdump was segfaulting.

> would just removing the "have_saved_context = 0;" from
> do_windows_fetch_inferior_registers fix the problem?

But them we need to be really careful about to where
we should reset it to zero, otherwise we might end up 
by still copying saved_context, even after having reran the debuggee, no?

Pierre



  reply	other threads:[~2009-09-21 22:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-21 15:15 Pierre Muller
2009-09-21 22:26 ` Christopher Faylor
2009-09-21 22:35   ` Pierre Muller [this message]
2009-09-21 23:01     ` [RFA-v2] windows-nat.c Cygwin saved_context fix Pierre Muller
2009-09-22 13:32       ` Christopher Faylor
2009-09-22 22:35         ` Pierre Muller
2009-09-22 13:30     ` [RFA] windows-nat.c Cygwin save_context fix Christopher Faylor

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='000001ca3b0b$d8310250$889306f0$@u-strasbg.fr' \
    --to=muller@ics.u-strasbg.fr \
    --cc=gdb-patches@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