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

[Eli Zaretskii <eliz@gnu.org>]

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

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

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

"compile code", I think.

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

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

"compile file"

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

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

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

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

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

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

Thanks.