From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27281 invoked by alias); 5 Nov 2005 02:46:13 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 27203 invoked by uid 22791); 5 Nov 2005 02:46:09 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sat, 05 Nov 2005 02:46:09 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EYE4E-0005TI-Aj; Fri, 04 Nov 2005 21:46:06 -0500 Date: Sat, 05 Nov 2005 02:46:00 -0000 From: Daniel Jacobowitz To: Andrew STUBBS Cc: gdb@sources.redhat.com Subject: Re: RFC: GDB as a loader 2/3: return child result Message-ID: <20051105024606.GA20989@nevyn.them.org> Mail-Followup-To: Andrew STUBBS , gdb@sources.redhat.com References: <4354DC55.4090706@st.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4354DC55.4090706@st.com> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-11/txt/msg00116.txt.bz2 On Tue, Oct 18, 2005 at 12:28:21PM +0100, Andrew STUBBS wrote: > Hi all, > > The attached patch implements a new option --return-child-result. This > option causes GDB to return the return value of the last child > (inferior) program to run. The patch assumes that the batch-silent patch > has already been applied. > > Note that 'quit ' still works as expected. Also, any exit through > a mechanism other than quit_force (i.e. errors) gives the same exit code > as it did before. Batch mode has been adjusted to exit through > quit_force in order to ensure it give the right result. > > I am not sure that this has been implemented in the best way. The > declaration of extern variables probably ought to be moved to a header > file somewhere, but I'm not sure which is best. It has also been > suggested that it ought to use the value stored in the existing > $_exitcode convenience variable. Sorry, I never got around to looking at the code portion of this. Would you mind making one cleanup for me? It doesn't really matter which header the externs go in. But they have to go in a header, visible at both the point of definition and the point of use. No externs in C files. top.h or main.h should be fine. Otherwise it looks great. Thanks. -- Daniel Jacobowitz CodeSourcery, LLC