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


> 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.

> >> +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.


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