From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24508 invoked by alias); 20 Jun 2014 09:17:27 -0000 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 Received: (qmail 24495 invoked by uid 89); 20 Jun 2014 09:17:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 20 Jun 2014 09:17:25 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5K9HMe6030248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 20 Jun 2014 05:17:22 -0400 Received: from localhost.localdomain (ovpn-112-22.ams2.redhat.com [10.36.112.22]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5K9HKF9015818; Fri, 20 Jun 2014 05:17:21 -0400 Message-ID: <53A3FC20.4030408@redhat.com> Date: Fri, 20 Jun 2014 09:17:00 -0000 From: Phil Muldoon MIME-Version: 1.0 To: Eli Zaretskii CC: gdb-patches@sourceware.org, tromey@redhat.com Subject: Re: (Doc ping [for news and manual]) -- [PATCH 14/14] the "compile" command References: <1400253995-12333-1-git-send-email-tromey@redhat.com> <1400253995-12333-15-git-send-email-tromey@redhat.com> <539EBEF2.5010703@redhat.com> <83ha3kvpv5.fsf@gnu.org> In-Reply-To: <83ha3kvpv5.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-06/txt/msg00730.txt.bz2 On 16/06/14 16:25, Eli Zaretskii wrote: >> Date: Mon, 16 Jun 2014 10:54:58 +0100 >> From: Phil Muldoon >> CC: Tom Tromey , "eliz@gnu.org" Thanks. I've made the changes you have requested. Tom plans to post the whole patch-set again soon. If required, I can just post the doc changes here. Otherwise, the changes will be part of the next patch-set. Comments in-line. >> +@value{GDBN}, or the compiler does not support this feature > > I think it would be good to say here which compiler(s) in what > version(s) started supporting this feature. We actually don't have one yet. That will change soon. The GCC changes are being reviewed now (this project is a cross GCC/GDB project). Once there is a released version number associated with a GCC version, I will add a "since GCC version ...". >> +compiles and links successfully, @value{GDBN} will load the object-code >> +emitted, and execute it within the context of the currently selected >> +inferior. > > When you say "and execute it", you don't mean right away, yes? > Because that's what the text conveys. Will the execution commence > immediately, or only when the program counter gets to this code? Yes right away. The object code is loaded and placed in a dummy frame and executed immediately. Some later plans yet to be implemented will need the object code to stick around and execute at arbitrary points (I.E., fast breakpoints with the object code being patched into the inferior). But those features do not exist yet. When those features become available I will submit a new doc patch describing when the object code executes immediately, when it is deferred, and also describe the life-cycle. >> +When the language in @value{GDBN} is set to @samp{C}, the compiler will >> +attempt to compile the source code with a @samp{C} compiler. The source > > This begs the question: how will GDB know which compiler to invoke and > by what name? GDB invokes the GCC plugin which deals with this kind of housekeeping. GDB loads libcc1.so and calls the exported functions in that library. So from a GDB point of view, we don't care how the compiler is invoked, or on the selection of the compiler (we'll, we do care, but we trust in the GCC plugin to do the right thing). >> +A compiler error would be raised as the variable @var{ff} no longer >> +exists. > > This text hints, for the first time, that the compiled code is thrown > away once it finishes execution. I've written an explanation in the "compile command" section to warn of the life-cycle of the object code, including the treatment of new types and variables. > Can the compile command access registers? There's no definitive answer to this question. "It depends" is the best answer I can give. If the language the compile command is compiling allows direct register access then yes, otherwise no. We do not prohibit the user doing anything in the language they could normally do if they wrote the program with a text editor and compiled it with GCC themselves. Hope that helps Cheers, Phil