From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20921 invoked by alias); 9 Mar 2004 02:41:06 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 20896 invoked from network); 9 Mar 2004 02:41:03 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 9 Mar 2004 02:41:03 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 08F4B2B92; Mon, 8 Mar 2004 21:40:58 -0500 (EST) Message-ID: <404D2EB9.10607@gnu.org> Date: Tue, 09 Mar 2004 02:41:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Ulrich Weigand Cc: gdb@sources.redhat.com Subject: Re: getpid after vfork broken in recent glibc References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00058.txt.bz2 > Hello, > > in fork_inferior (fork-child.c), gdb uses vfork () to spawn a child > process, and then calls getpid () (within gdb_setpgid) from within > that child process, before doing the execve (). > > With current glibc CVS builds, this doesn't work any more, since > glibc caches the PID in thread-local memory, and memory is shared > between vfork parent and child. (In fact, what happens is that > all subsequent getpid calls in gdb return the pid of the initial > child that was spawned ...) This causes various breakage. > > Now, according to this libc-hacker thread: > http://sources.redhat.com/ml/libc-hacker/2004-03/msg00014.html > gdb's behaviour is actually not standards-compliant, as it is not > permitted to call getpid () between the vfork and the exec. > > Can this be fixed in gdb? We might as well simply always use fork -- the "performance" benefit is hardly valid any more (Hmm, perhaps something related to this is why vfork never worked, and hence was disabled, on HP/UX). Andrew