From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27792 invoked by alias); 20 Jun 2014 10:01:12 -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 27781 invoked by uid 89); 20 Jun 2014 10:01:11 -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 10:01:10 +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 s5KA18Aq011368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 20 Jun 2014 06:01:08 -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 s5KA16ad005351; Fri, 20 Jun 2014 06:01:07 -0400 Message-ID: <53A40662.60708@redhat.com> Date: Fri, 20 Jun 2014 10:01: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> <53A3FC20.4030408@redhat.com> <837g4bsys6.fsf@gnu.org> In-Reply-To: <837g4bsys6.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-06/txt/msg00733.txt.bz2 On 20/06/14 10:42, Eli Zaretskii wrote: >> 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. No, how can there be plans to slot it into a version when it is under review? I would suspect "the next version that GCC releases" but I am unfamiliar with how GCC does its release versioning. Minor/Major and so on. I don't reject your idea, I just don't know how to give a version when there is no version yet. >>>> +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. Why? Is compiling not happening? What other command names do you suggest? >>>> +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?)? Tom could maybe answer this better. There was recent work on the GCC triplet and PATH searching over on GCC for the plugin. Note, we do not do anything to the existing inferior in the compilation step. We only compile the code specified in the compile command. We just use a number of methods to do this (namely a symbol/type "Oracle" to tell GCC about type inferences in the compiled code.) > 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? I'll defer this to Tom. >>> 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. I did not say it could not. If the language that the compiled code allows access to registers then register access is possible. If not, then how can the compile command do anything? If it is a limitation, then it is a limitation of the language currently used, not the command. There is only one language supported so far, and that language is C. If C syntax allows access to registers, great, poke away at registers. If not, I don't understand how we can provide a C or other language syntax to provide access. We are just compiling the language, not providing a new syntax. Cheers, Phil