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

[Phil Muldoon <pmuldoon@redhat.com>]

On 20/06/14 10:42, Eli Zaretskii wrote:
>> Date: Fri, 20 Jun 2014 10:17:20 +0100
>> From: Phil Muldoon <pmuldoon@redhat.com>
>> 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