public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH v3 14/14] the "compile" command
Date: Sun, 02 Nov 2014 16:03:00 -0000	[thread overview]
Message-ID: <8361exy4if.fsf@gnu.org> (raw)
In-Reply-To: <20141101214733.13230.49968.stgit@host1.jankratochvil.net>

> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Date: Sat, 01 Nov 2014 22:47:33 +0100
> 
> diff --git a/gdb/NEWS b/gdb/NEWS
> index 649c29e..c4a6c6a 100644
> --- a/gdb/NEWS
> +++ b/gdb/NEWS

This part is OK.

> +@value{GDBN} supports on-demand compilation and code injection into
> +programs running under @value{GDBN}.  GCC 5.0 or higher built with
> +@code{libcc1.so} must be installed for this functionality to be enabled.

libcc1.so should be in @file, not @code.

> +Compile @var{source} with the compiler language set as the current
> +language in @value{GDBN} (@pxref{Languages}).

Does the user need to set the language, or will the language from the
debug info be used, if available?  If the latter, the wording here
needs to be modified, as it currently implies one needs to set the
language "in GDB".

> If compilation and
> +injection is not supported with the current language specified in
> +@value{GDBN}, or the compiler does not support this feature,

Which "this feature" needs to be supported by the compiler?

> +message will be printed.  If @var{source} compiles and links
> +successfully, @value{GDBN} will load the object-code emitted,

Judging by the example, I would suggest to use @var{source-code}
instead of @var{code}.

> +The command allows you to specify source code in two ways.  The simplest

@var{code}, so that the reader realizes you are talking about the
argument mentioned above.

> +Specifying @samp{-raw}, prohibits @value{GDBN} from wrapping the
> +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{-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

I think an example of using 'raw' is in order; the description above
is not very clear.

> +@samp{#include} lines are better to be placed before the @samp{#pragma}
> +line.

Why? what happens if one doesn't?

>        The use of @samp{-raw} is considered to be expert usage, and care
> +should be taken when using it.

Like what?

This kind of remarks in documentation are "considered harmful": either
explain in detail what you mean, or don't say that at all.  Leaving
mysterious comments about "here be dragons" doesn't help the reader
understand how to use the feature correctly.

> +If the filename/path contains whitespace it must be enclosed in
> +quotes.

Which quotes? single? double?

> +There are a few caveats to keep in mind when using the @code{compile}
> +command.  As the caveats are different per language, the table below
> +highlights specific issues on a per language basis.

This and the following stuff is better put in its own subsection.

> +@code{C}.  Be aware that changes to inferior variables in the
> +@code{compile} command are persistent.  In the following example:
> +
> +@smallexample
> +compile code k = 3;
> +@end smallexample
> +
> +The variable @code{k} is now 3.

You want this line be continuation of the one before the example.  So:

 @noindent
 the variable @code{k} is now 3.

>                                   It will remain that value until
                                            ^^^^^^
"retain", not "remain".

> +something else in the example program changes it, or another
> +@code{compile} command changes it.

So why did you say the changes are persistent?  Persistent might mean
the value will be the same if the program is re-run.

> +Normal scope and access rules apply to source code compiled and injected
> +by the @code{compile} command.  In the example, the variables @code{j}
> +and @code{k} are not accessible; subsequent execution will bring these
> +variables into scope, and later, code written and compiled with the
> +@code{compile} command will be able to access them.  At this point the
> +program is stopped in the @code{main} function so the following example:
> +
> +@smallexample
> +compile code j = 3;
> +@end smallexample
> +
> +would result in a compilation error, and @value{GDBN} would print that
> +error to the console.

I needed to read this twice to understand what you mean.  Suggest to
reword as follows:

  Normal scope and access rules apply to source code compiled and
  injected by the @code{compile} command.  In the example, the variables
  @code{j} and @code{k} are not accessible yet, because the program is
  currently stopped in the @code{main} function, where these variables
  are not in scope.  Therefore, the following command

  @smallexample
  compile code j = 3;
  @end smallexample

  @noindent
  will result in a compilation error message.

  Once the program is continued, execution will bring these variables in
  scope, and they will become accessible; then the code you specify via
  the @code{compile} command will be able to access them.

> +However, if you were to type the following into @value{GDBN} after that
> +command has completed:
> +
> +@smallexample
> +compile code printf ("ff is %d\n'', ff);
> +@end smallexample
> +
> +A compiler error would be raised as the variable @code{ff} no longer

Again, @noindend after the @example, and start "a compiler error" with
a lower-case letter, as this is a continuation of the sentence before
the example.

> +exists.  Object code generated and injected by the @code{compile}
> +command is removed on completion of the command.

"... is removed when its execution ends" is better.  ("Completion of
the command" is not well-defined.)

>                                                        Caution is advised
> +when assigning variables belonging to the program with variables created
> +in the @code{compile} command.

"assigning to program variables values of variables created by the
code submitted to the @code{compile} command."

> +The @code{k} variable is assigned to the value of @code{ff}.  The variable
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
"The value of the variable @code{ff} is assigned to @code{k}."

> +@code{k} does not require the existence of @code{ff} to maintain the value
> +it has been assigned.  Pointers and other types of references require

"However, pointers ..."

What "other types"?  How about one or two examples?

> +location when the command exists.  A general rule should be followed
> +in that you should either assign @code{NULL} to any assigned pointers,
> +or restore a valid location to the pointer before the command exits.

Why NULL?  Any constant address will do, right?

> +Similar caution must be exercised with any types defined in
> +@code{compile} command.

I would explain what you mean by "defined types" here.  I'm guessing
you mean structs, unions, and typedefs, but let's say this explicitly.

>                             Types defined in the @code{compile} are also
> +deleted when the command exits.

I think types are not deleted, they simply don't exist in compiled
code.  Right?

>                                    Therefore, if you cast a variable to a
> +type defined in the @code{compile} command, care must be taken to ensure
> +that any future need to resolve the type can be achieved.

I don't understand the meaning of this.  Defining a type and casting
to a type are two different things, so what does this text warn about?

> +Variables that have been optimized away by the compiler are not
> +accessible to the @code{compile} command.

"... not accessible to the code submitted to the @code{compile} command"

Thanks.

  reply	other threads:[~2014-11-02 16:03 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-01 21:45 [PATCH v3 00/14] let gdb reuse gcc's C compiler Jan Kratochvil
2014-11-01 21:46 ` [PATCH v3 06/14] add infcall_mmap and gcc_target_options gdbarch methods Jan Kratochvil
2014-11-01 21:46 ` [PATCH v3 07/14] add gnu_triplet_regexp gdbarch method Jan Kratochvil
2014-11-01 21:46 ` [PATCH v3 02/14] add gcc/gdb interface files Jan Kratochvil
2014-11-03 12:51   ` Yao Qi
2014-11-03 12:56     ` Jan Kratochvil
2014-11-03 13:24       ` Yao Qi
2014-11-01 21:46 ` [PATCH v3 08/14] introduce call_function_by_hand_dummy Jan Kratochvil
2014-11-01 21:46 ` [PATCH v3 04/14] add make_unqualified_type Jan Kratochvil
2014-11-01 21:46 ` [PATCH v3 03/14] add some missing ops to DWARF assembler Jan Kratochvil
2014-11-01 21:46 ` [PATCH v3 01/14] introduce ui_file_write_for_put Jan Kratochvil
2014-11-01 21:46 ` [PATCH v3 05/14] add dummy frame destructor Jan Kratochvil
2014-11-01 21:47 ` [PATCH v3 13/14] add s390_gcc_target_options Jan Kratochvil
2014-11-01 21:47 ` [PATCH v3 11/14] export dwarf2_reg_to_regnum_or_error Jan Kratochvil
2014-11-01 21:47 ` [PATCH v3 09/14] split dwarf2_fetch_cfa_info from dwarf2_compile_expr_to_ax Jan Kratochvil
2014-11-01 21:47 ` [PATCH v3 10/14] make dwarf_expr_frame_base_1 public Jan Kratochvil
2014-11-01 21:47 ` [PATCH v3 12/14] add linux_infcall_mmap Jan Kratochvil
2014-11-11 16:43   ` Pedro Alves
2014-11-23 19:11     ` Jan Kratochvil
2014-12-12 14:38       ` Pedro Alves
2014-11-01 21:48 ` [PATCH v3 14/14] the "compile" command Jan Kratochvil
2014-11-02 16:03   ` Eli Zaretskii [this message]
2014-11-20 21:24     ` Jan Kratochvil
2014-11-21  7:58       ` Eli Zaretskii
2014-11-21 18:41         ` Jan Kratochvil
2014-11-21 19:47           ` Eli Zaretskii
2014-11-03 13:08   ` Yao Qi
2014-11-14 18:43     ` Jan Kratochvil
2014-11-11 18:53   ` Pedro Alves
2014-11-23 18:36     ` Jan Kratochvil
2014-12-12 14:38       ` Pedro Alves
2014-11-01 21:52 ` [PATCH v3 00/14] let gdb reuse gcc's C compiler Jan Kratochvil
2014-11-01 21:56 ` Jan Kratochvil
2014-11-03 12:47 ` Yao Qi
2014-11-03 12:49   ` Jan Kratochvil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8361exy4if.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).