From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14945 invoked by alias); 14 Jun 2006 14:25:59 -0000 Received: (qmail 14935 invoked by uid 22791); 14 Jun 2006 14:25:58 -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; Wed, 14 Jun 2006 14:25:54 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FqWJc-0003zm-95; Wed, 14 Jun 2006 10:25:52 -0400 Date: Wed, 14 Jun 2006 14:25: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: <20060614142552.GA15021@nevyn.them.org> Mail-Followup-To: Jan Kratochvil , gdb-patches@sourceware.org References: <20060614105510.GA12067@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060614105510.GA12067@host0.dyn.jankratochvil.net> 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-06/txt/msg00218.txt.bz2 On Wed, Jun 14, 2006 at 12:55:10PM +0200, Jan Kratochvil wrote: > It is only a heuristic as execve(2) destroys %gs and gdb(1) fails to find the > no longer existing threads through TLS. Patch will warn and turn off the gdb(1) > threads support if it finds out %gs==0. > > On i386 with %gs based TLS NPTLS gdb calls glibc td_ta_map_lwp2thr() which > calls ta_howto_reg_thread_area() (case ta_howto_reg_thread_area). > After execve(2) it retrieves %gs as 0 and fails to ps_get_thread_area() > as its idx must be 6 (glibc TLS descriptor) - value of the first/glibc Linux > kernel GDT_ENTRY_TLS_MIN. > It is now workarounded as to drop threading support if %gs==0. > > Do you have an idea for a cleaner solution than this hack of waiting till the > threads are no longer accessible? Not aware of some indication which kernel > syscall will replace the whole process memory space and the process registers. Your problem combines two different issues: - libthread_db doesn't do anything sensible at the beginning of execution, before libpthread is initialized. I filed a bug in the glibc bugzilla about this with a possible patch. - gdb thinks threading is still active after an exec. We already have a way to detect exec events: PTRACE_EVENT_EXEC. Support for it is disabled, because it really doesn't work very well, and no one has volunteered to fix it. The way we handle it doesn't make much sense; gdb silently switches the current executable file from the old program to the new programl which messes up what happens when the user says "run". But if you wanted to support any kind of execve debugging, that would be the way to do it. Oh, and please don't add more tests to the testsuite which would spin forever if detached from GDB; we've already got a few and I'm convinced in hindsight that it was a mistake. You only need it to exec once, so you could make it quietly exit the second time. -- Daniel Jacobowitz CodeSourcery