[PATCH v2 14/14] the "compile" command

[Jan Kratochvil]

On Fri, 20 Jun 2014 21:16:49 +0200, Eli Zaretskii wrote:
> > From: Tom Tromey <tromey@redhat.com>
> > Cc: Tom Tromey <tromey@redhat.com>
> > Date: Fri, 20 Jun 2014 09:57:54 -0600
> > 
> > +* GDB now supports the compilation and injection of source code into
> > +  the inferior.  GDB will use a feature-capable compiler to compile
> > +  the source code to object code, and if successful, inject and
> > +  execute that code within the current context of the inferior.
> 
> Like I said, we should at least mention GCC and likely also the name
> of the plugin needed to support this feature.  users should be able to
> quickly discover whether their compiler supports this.

Done.
  the inferior.  GDB will use GCC 5.0 or higher built with libcc1.so
  to compile the source code to object code, and if successful, inject 


> > +  Currently the C language is supported.  The commands used to
> > +  interface with this new feature are:
> > +
> > +     compile code [-raw|-r] [--] [source code]
> > +     compile file [-raw|-r] filename
> > +
> >  * GDB supports printing and modifying of variable length automatic arrays
> >    as specified in ISO C99.
> >  
> > @@ -33,6 +43,15 @@ guile-repl
> >  gr
> >    Start a Guile interactive prompt (or "repl" for "read-eval-print loop").
> >  
> > +compile code [-r|-raw] [--] [source code]
> > +  Compile and inject into the inferior the executable object code
> > +  produced by compiling the provided source code.
> 
> "Compile, inject, and execute", I think.

Done, not sure if right:
  Compile, inject, and execute in the inferior the executable object 
  code produced by compiling the provided source code.


> > +Evaluate a block of source code.\n\
> > +\n\
> > +Usage: code [-r|-raw] [--] [CODE]\n\
> 
> "compile code", I think.

I think we should therefore follow your sentence above, therefore used:

Compile, inject, and execute code.\n\
\n\
Usage: compile code [-r|-raw] [--] [CODE]\n\


> > +The source code may be specified as a simple one line expression, e.g:\n\
>                                                                      ^^^
> Period missing.

Done.


> > +Usage: file [-r|-raw] [filename]\n\
> 
> "compile file"

Also changed "code"->"compile code" above, thanks.

Usage: compile file [-r|-raw] [filename]\n\


> > +  /* Override flags possibly coming from DW_AT_producer.  */
> > +  compile_args = xstrdup ("-O0 -gdwarf-4"
> 
> This cannot be a fixed setting, I think.  E.g., MinGW compilers barf
> when they see -gdwarf-4.

I have to disagree, -gdwarf-4 works for me.  One needs to build new GCC for
libcc1.so anyway.

$ for i in x86_64-w64-mingw32-gcc i686-w64-mingw32-gcc;do $i --version|head -n1;echo 'main(){}'|$i -gdwarf-4 -x c -;file a.exe;objdump -Wi a.exe|egrep 'Version:|DW_AT_comp_dir'|grep -B1 /tmp|head -n1;done
x86_64-w64-mingw32-gcc (GCC) 4.8.3 20140522 (Fedora MinGW 4.8.3-1.fc20)
a.exe: PE32+ executable (console) x86-64, for MS Windows
   Version:       4
i686-w64-mingw32-gcc (GCC) 4.8.3 20140522 (Fedora MinGW 4.8.3-1.fc20)
a.exe: PE32 executable (console) Intel 80386, for MS Windows
   Version:       4


> > +  /* We use -fPIC to ensure that we can reference properly.  Otherwise
> > +     on x86-64 a string constant's address might be truncated when gdb
> > +     loads the object; another approach would be -mcmodel=large, but
> > +     -fPIC seems more portable across back ends.  */
> > +			 " -fPIC"
> > +  /* We don't want warnings.  */
> > +			 " -w"
> > +  /* Override CU's possible -fstack-protector-strong.  */
> > +			 " -fno-stack-protector"
> 
> Likewise: these are architecture dependent switches, they cannot be
> fixed constants, I think.

These options work for me for x86_64-w64-mingw32-gcc and i686-w64-mingw32-gcc.

This whole "gdbjit" feature cannot work seamlessly with absolutely any arch.
There are issues like matching the ABI inferior program is compiled with and
also issues around PIC code vs. far references etc.  This is why some parts of
this GDB "gdbjit" patchset depends on gdbarch hooks.

After someone finds an arch s/he wants the "gdbjit" support for, it will be
incompatible with some generic parts of this patchset and there will be
a solution how to make that working on that arch we can move that specific
part of code into gdbarch hook.  Currently I am not aware how to replace these
options if they do not work as is on some target.


> > +@value{GDBN} supports on-demand compilation and code injection into
> > +programs running under @value{GDBN}.  A suitable compiler must be
> > +installed for this functionality to be enabled.  This functionality is
> > +implemented with the following commands.
> 
> My request still stands to mention GCC and perhaps its version or some
> other attribute that would make it easy to determine that the feature
> is supported.

Done.

programs running under @value{GDBN}.  GCC 5.0 or higher built with
@code{libcc1.so} must be installed for this functionality to be enabled.
This functionality is implemented with the following commands.


> > +language in @value{GDBN} (@pxref{Languages}).  If compilation and
> > +injection is not supported with the current language specified in
> > +@value{GDBN}, or the compiler does not support this feature, an error
> > +message will be printed and the command will exit.  If @var{source}
> 
> The "and the command will exit" part is misleading, suggest to remove
> it (it doesn't add anything useful to the description).

Done.


> > +Specifying @samp{-@var{raw}}, prohibits @value{GDBN} from wrapping the
> 
> Please remove the @var part and the braces (here and elsewhere), it is
> incorrect here, since "raw" is a literal string.

Done.

@itemx compile code -raw @var{--} @var{source}
Specifying @samp{-raw}, prohibits @value{GDBN} from wrapping the
@code{_gdb_expr_}.  The @samp{-raw} code does not automatically
line.  The use of @samp{-raw} is considered to be expert usage, and care
@itemx compile file -raw @var{filename}


> > +provided @var{source} in a callable scope.  In this case, you must
> > +specify the entry point of the code by defining a function named
> > +@code{_gdb_expr_}.  The @samp{-@var{raw}} code does not automatically
> > +access variables of the inferior, for their import you must use the
> > +@samp{#pragma} line first:
> > +
> > +@smallexample
> > +#pragma GCC user_expression
> > +@end smallexample
> > +
> > +@samp{#include} lines are better to be placed before the @samp{#pragma}
> > +line.  The use of @var{raw} is considered to be expert usage, and care
>                      ^^^^^^^^^
> @code{-raw}

Done above.

line.  The use of @samp{-raw} is considered to be expert usage, and care


Thanks,
Jan
-------------- next part --------------
An embedded message was scrubbed...
From: Tom Tromey <tromey@redhat.com>
Subject: [PATCH] the "compile" command
Date: Wed, 14 May 2014 14:35:45 -0600
Size: 213745
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20141008/8ed30b74/attachment.eml>