From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30498 invoked by alias); 9 Feb 2008 16:53:55 -0000 Received: (qmail 30487 invoked by uid 22791); 9 Feb 2008 16:53:54 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 09 Feb 2008 16:53:31 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 80A2198300; Sat, 9 Feb 2008 16:53:29 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 65A059814D; Sat, 9 Feb 2008 16:53:29 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1JNsxE-0000tv-Cj; Sat, 09 Feb 2008 11:53:28 -0500 Date: Sat, 09 Feb 2008 16:53:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: gdb-patches@sourceware.org Subject: Re: RFC: Allow a wrapper when starting programs Message-ID: <20080209165328.GA3161@caradoc.them.org> Mail-Followup-To: Eli Zaretskii , gdb-patches@sourceware.org References: <20080208185727.GA30185@caradoc.them.org> <20080209154834.GA32141@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-12-11) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-02/txt/msg00166.txt.bz2 On Sat, Feb 09, 2008 at 06:40:48PM +0200, Eli Zaretskii wrote: > Maybe, but it's better not to create an impression that this is > supported universally. To make the burden easier, we could say > something like "this is supported by only some platforms". > > > Every native (non-remote) target uses fork-child, except for DJGPP, > > Cygwin, mingw32, and QNX NTO. > > DJGPP is not important enough to care, but Cygwin is, and so are (to a > lesser extent, I think) MinGW and NTO. Yeah. Listing them is probably best. > > > > + The wrapper will run until its first > > > > +debug trap before @value{GDBN} takes control. > > > > + > > > > +On Unix systems, a debug trap (@code{SIGTRAP}) is generated at the > > > > +@code{execve} system call. This allows any program which uses > > > > +@code{execve} to start another program to be used as a wrapper. > > > > > > This is not detailed enough to be useful to anyone but a GDB hacker > > > who also happened to read the respective portions of the code in > > > fork-child.c. In any case, it left me wondering what is this all > > > about, and why I, as a GDB user, should care about SIGTRAPs. > > > > > > IOW, if this is important for the user to know, we should explain the > > > issue in terms understandable by a GDB user. > > > > This is where I get stuck. I did the best I could, but the effect of > > waiting for an extra trap is hard to describe except in terms of > > signals or examples. I don't know what else to add. > > Try me: if you explain why all this is needed, I might find a way to > describe that in the manual. For starters, why do we need to wait for > an extra trap? Sure. We're waiting for an extra trap for the same reason we currently wait for two (on most systems; sometimes varies). We normally fork and then execute a command like this one: sh -c 'exec your-program' The first trap is generated when gdb execs sh. At this point we know where the child is, but it's at the wrong place. The loaded binary is sh, not your-program, so we can't set breakpoints in your-program. With a wrapper, we run: sh -c 'exec wrapper your-program' So after two traps, the loaded program is wrapper. If we gave control to the user or tried to insert breakpoints at your-program's symbols, things would go wrong. We have to wait until the loaded program is finally your-program. There's no portable way to check what the loaded program is, and even if there were it wouldn't help enough; wrapper and your-program might be the same binary (a corner case, I admit). -- Daniel Jacobowitz CodeSourcery