From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14648 invoked by alias); 20 Jun 2014 09:42:19 -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 14634 invoked by uid 89); 20 Jun 2014 09:42:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout24.012.net.il Received: from mtaout24.012.net.il (HELO mtaout24.012.net.il) (80.179.55.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 20 Jun 2014 09:42:17 +0000 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0N7G00D00O209900@mtaout24.012.net.il> for gdb-patches@sourceware.org; Fri, 20 Jun 2014 12:38:12 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N7G008J6O3OPN40@mtaout24.012.net.il>; Fri, 20 Jun 2014 12:38:12 +0300 (IDT) Date: Fri, 20 Jun 2014 09:42:00 -0000 From: Eli Zaretskii Subject: Re: (Doc ping [for news and manual]) -- [PATCH 14/14] the "compile" command In-reply-to: <53A3FC20.4030408@redhat.com> To: Phil Muldoon Cc: gdb-patches@sourceware.org, tromey@redhat.com Reply-to: Eli Zaretskii Message-id: <837g4bsys6.fsf@gnu.org> 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> <53A3FC20.4030408@redhat.com> X-IsSubscribed: yes X-SW-Source: 2014-06/txt/msg00731.txt.bz2 > Date: Fri, 20 Jun 2014 10:17:20 +0100 > From: Phil Muldoon > CC: gdb-patches@sourceware.org, tromey@redhat.com > > >> +@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 ...". Aren't there plans in place to make this part of a known GCC version, or maybe a branch where these changes are being made is already slated to be included in some known version? If so, please state that version; it can be changed later if plans change or life intervenes. But even saying it's a GCC feature is already much more than we tell now. > >> +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. Then I guess "compile" is a misleading name. > >> +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. That's not what I meant. Suppose I have 2 compilers installed, one called 'gcc', the other 'gcc472'. (They could also be in different directories, even not on PATH.) The program I'm debugging was compiled with gcc472. How will GDB know to invoke that executable? Also, how would it know the command-line arguments required to produce a code that will work well with the rest of the program being debugged (the code I compile can call functions in the program, right?)? If the wrong compiler or the wrong switches will be used, the result might be crashes or other surprises. > 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). The GCC plugin is part of the compiler. What if I have more than one? > > 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. But GDB knows how to access registers regardless of the language. Why cannot the compiled code use those facilities? It sounds like a limitation, especially when the program being debugged was compiled with optimizations.