Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: RFC: Fix crash on i386 (%gs-)threaded programs using execve(2)
Date: Mon, 24 Jul 2006 19:03:00 -0000	[thread overview]
Message-ID: <20060724190332.GA13612@nevyn.them.org> (raw)
In-Reply-To: <20060722123102.GA1936@lace.redhat.com>

On Sat, Jul 22, 2006 at 02:31:02PM +0200, Jan Kratochvil wrote:
> Hi Daniel,
> 
> please commit if appropriate:
> 
> Created the attached minimal patch fixing the gdb lockup.
> 
> 2006-07-22  Jan Kratochvil  <jan.kratochvil@redhat.com>
> 
> 	* linux-thread-db.c (thread_db_wait): Avoid locking up on stale
> 	threading state after TARGET_WAITKIND_EXECD.

Thanks.  I've committed the attached version; I played around with it a
little bit, and discovered that you couldn't re-run unless you remember
to remove the thread breakpoints too.

> On Fri, 21 Jul 2006 20:44:21 +0200, Daniel Jacobowitz wrote:
> ...
> > Turning on MAY_FOLLOW_EXEC is not a good idea.  No one really knows how
> > that behavior works, a lot of it doesn't, and the way it implicitly
> > changes the symbol file is very disorienting.  Please don't mix it up
> > with the fix for your current bug.
> 
> Still I am for MAY_FOLLOW_EXEC as it improves the user experience and makes
> debugging of exec()ing processes much more convenient - without having to find
> out how each child gets executed and replay such conditions by hand.
> 
> As gdb-6.5 has been released and the MAY_FOLLOW_EXEC feature IMO generally
> works for GNU/Linux - isn't appropriate to enable it and settle it down?
> I would even like to fix any issues possibly roaring its head.

Does anyone else have an opinion on this?  I'm starting to think you're
right - we should turn it on, invite people to use it, and see what
happens.

The reason I find it so disorienting is this:

% gdb file1

(gdb) run
[starts file1]
[file1 execs file2]
[file2 exits]

(gdb) run
[file2 starts instead of file1!]

I don't know if it should do that or not.  I tend to use "run" a lot
and want to get back to the beginning of my debug session.

-- 
Daniel Jacobowitz
CodeSourcery

2006-07-24  Jan Kratochvil  <jan.kratochvil@redhat.com>
	    Daniel Jacobowitz  <dan@codesourcery.com>

	* linux-thread-db.c (thread_db_wait): Remove libthread_db
	after exec events.

Index: linux-thread-db.c
===================================================================
RCS file: /cvs/src/src/gdb/linux-thread-db.c,v
retrieving revision 1.17
diff -u -p -r1.17 linux-thread-db.c
--- linux-thread-db.c	18 Jul 2006 22:53:20 -0000	1.17
+++ linux-thread-db.c	24 Jul 2006 18:56:24 -0000
@@ -875,6 +875,15 @@ thread_db_wait (ptid_t ptid, struct targ
   if (ourstatus->kind == TARGET_WAITKIND_EXITED)
     return pid_to_ptid (-1);
 
+  if (ourstatus->kind == TARGET_WAITKIND_EXECD)
+    {
+      remove_thread_event_breakpoints ();
+      unpush_target (&thread_db_ops);
+      using_thread_db = 0;
+
+      return pid_to_ptid (GET_PID (ptid));
+    }
+
   if (ourstatus->kind == TARGET_WAITKIND_STOPPED
       && ourstatus->value.sig == TARGET_SIGNAL_TRAP)
     /* Check for a thread event.  */


  reply	other threads:[~2006-07-24 19:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-14 10:55 Jan Kratochvil
2006-06-14 14:25 ` Daniel Jacobowitz
2006-06-15 20:36   ` Jan Kratochvil
2006-07-21 18:16     ` Jan Kratochvil
2006-07-21 18:44       ` Daniel Jacobowitz
2006-07-22 12:31         ` Jan Kratochvil
2006-07-24 19:03           ` Daniel Jacobowitz [this message]
2006-07-29 18:54             ` [patch] Linux MAY_FOLLOW_EXEC #2 [Re: RFC: Fix crash on i386 (%gs-)threaded programs using execve(2)] Jan Kratochvil
2006-07-31 20:39               ` Mark Kettenis
2006-08-05 16:43                 ` [patch] Linux MAY_FOLLOW_EXEC #2 Jan Kratochvil
2006-08-08 16:01                   ` Daniel Jacobowitz

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=20060724190332.GA13612@nevyn.them.org \
    --to=drow@false.org \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.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