This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v3 14/14] the "compile" command
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 21 Nov 2014 09:58:30 +0200
- Subject: Re: [PATCH v3 14/14] the "compile" command
- Authentication-results: sourceware.org; auth=none
- References: <20141101214552 dot 13230 dot 45564 dot stgit at host1 dot jankratochvil dot net> <20141101214733 dot 13230 dot 49968 dot stgit at host1 dot jankratochvil dot net> <8361exy4if dot fsf at gnu dot org> <20141120212406 dot GA23190 at host2 dot jankratochvil dot net>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Date: Thu, 20 Nov 2014 22:24:06 +0100
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: gdb-patches@sourceware.org
>
> > > +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.
>
> The command "compile code k = 3;" makes the change persistent. Contrary to it
> command "compile code int k = 3;" would not be persistent which is described
> about 3 paragraphs beneath:
> Variables and types that are created as part
> of the @code{compile} command are not persistent, and only exist as
> long as the injected object code exists. This example is valid:
>
> @smallexample
> compile code int ff = 5; printf ("ff is %d\n", ff);
> @end smallexample
Then maybe we need to tell what "persistent" means in this context.
Something like "visible to the rest of the program for the duration of
this run".
> > > +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.
>
> TBH I do not agree with this formatting as the previous sentence has been
> terminated by its colon (':').
But then that previous sentence is incomplete, because it in effect
goes like "If you were to type the following: SOMETHING." A sentence
with an "if" but no "then" part is incomplete. I thought what follows
the @example is the "then" part, which is why I suggested those
changes.
> I see the difference as:
> See the expression: 1+2=3 Now we have to start a new sentence.
> See the expression 1+2=3 while here we continue the sentence.
These 2 examples are both fine, but they lack the "if" part, which is
what triggered my comment.
> > > 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?
>
> The meaning is that for example in a second "compile" command the types
> defined in previous "compile" command are no longer available.
OK, then let's say so explicitly. Something like
Types defined in the @code{compile} will no longer be available in
the next @code{compile} command.
> +If you specify options on the command line as well as source code, they
> +may conflict. The @samp{@var{--}} delimiter can be used to separate options
No need for @var here, as "--" is a literal string.
Otherwise, your new text is OK.
Thanks.