This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: (Doc ping [for news and manual]) -- [PATCH 14/14] the "compile" command


On 16/06/14 16:25, Eli Zaretskii wrote:
>> Date: Mon, 16 Jun 2014 10:54:58 +0100
>> From: Phil Muldoon <pmuldoon@redhat.com>
>> CC: Tom Tromey <tromey@redhat.com>, "eliz@gnu.org" <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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]