From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26751 invoked by alias); 21 Jul 2006 18:44:26 -0000 Received: (qmail 26743 invoked by uid 22791); 21 Jul 2006 18:44:26 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Fri, 21 Jul 2006 18:44:24 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1G3zz3-00060A-N9; Fri, 21 Jul 2006 14:44:21 -0400 Date: Fri, 21 Jul 2006 18:44:00 -0000 From: Daniel Jacobowitz To: Jan Kratochvil Cc: gdb-patches@sourceware.org Subject: Re: RFC: Fix crash on i386 (%gs-)threaded programs using execve(2) Message-ID: <20060721184421.GA22820@nevyn.them.org> Mail-Followup-To: Jan Kratochvil , gdb-patches@sourceware.org References: <20060614105510.GA12067@host0.dyn.jankratochvil.net> <20060614142552.GA15021@nevyn.them.org> <20060615203519.GA9603@host0.dyn.jankratochvil.net> <20060721181556.GA9150@lace.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060721181556.GA9150@lace.redhat.com> User-Agent: Mutt/1.5.11+cvs20060403 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-07/txt/msg00301.txt.bz2 On Fri, Jul 21, 2006 at 08:15:57PM +0200, Jan Kratochvil wrote: > Hi Daniel, > > I am now copyright assignment compliant (as Red Hat employee). > > The mail below was never replied; the patch still applies to the latest CVS. > Could you please review it? 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. It seems to me that you need thread_db_wait to check for EXECD, and pop the threading target off the stack when it happens. Maybe, if you want to be fancy, figure out the right place to push itself back on - but that's more troublesome to get right. unpush_target (&thread_db_ops); using_thread_db = 0; wipe the thread list?; return some the underlying process pid; -- Daniel Jacobowitz CodeSourcery