Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Eli Zaretskii" <eliz@gnu.org>
To: Joel Brobecker <brobecker@gnat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA/RFC] New command: ``start''
Date: Tue, 18 May 2004 06:32:00 -0000	[thread overview]
Message-ID: <6480-Tue18May2004093016+0300-eliz@gnu.org> (raw)
In-Reply-To: <20040518024700.GV10684@gnat.com>

> Date: Mon, 17 May 2004 19:47:00 -0700
> From: Joel Brobecker <brobecker@gnat.com>
> 
> As briefly discussed on gdb@ and gdb-patches@, here is a first proposal
> for the addition of a new command: ``start''.

Thanks.

> The other decision I made was to allow this new method to be undefined
> (NULL). In that case, we use "main" as the location where to insert the
> temporary breakpoint. I am not too sure about this approach, but I
> selected it because it avoids a xstrdup ("main")/xfree sequence.
> On the other hand, forcing the method to always be set would make the
> implemention clearer, I think, just at the expense of an unnecessary
> xstrdup/xfree sequence.

I think it's better to have a non-NULL string there.  The benfit is
that whoever reads the code doesn't need to look elsewhere to
understand what effect does NULL have there.

> +  if (current_language->la_xmain_procedure_name == NULL)
> +    {
> +      main_program_name = "main";
> +    }
> +  else
> +    {
> +      main_program_name =
> +        current_language->la_xmain_procedure_name ();
> +
> +      if (main_program_name == NULL)
> +        error ("Unable to get the main program name.");

If we use "main" when the method is NULL, we should also use "main"
if the method returns NULL, I think.

> +  c = add_com ("start", class_run, start_command,
> +               "\
> +Start the debugged program until the beginning of the main procedure.\n\

I think this should say "Run the debugged program until ...".  "Start
until" sounds like incorrect English.

> +Depending on the language, the name of the main procedure can vary.
> +With languages such as C or C++, the main procedure name is always

Please use "C@t{++}" instead of "C++", the former looks prettier in
print.

> +@code{main()}, but other languages such as Ada do not require a specific

Please say "@code{main}", without the parens.  "main()" looks like a
call to `main' with no arguments, which is not what you mean here.

> +The @code{start} command does the equivalent of setting a temporary
> +breakpoint at the beginning of the main procedure and then performing
> +a @code{run}.

`run' should be in @samp here, and I think "invoking the @samp{run}
command" is better than "performing a @samp{run}".

> Some programs contain an elaboration phase that will be
> +performed before the main procedure is reached, and it is possible that
> +the debugger will stop before reaching the main procedure. However,
> +the temporary breakpoint will remain to halt execution.

Sorry, I don't understand this part (what is ``elaboration''?).
Could you perhaps make this text more explanatory?

> +The arguments used when using this command are directly passed to the
> +@code{run} command.

You mean, if you type "run" thereafter, it will reuse the arguments
you type for the "start" command?  If so, we should reword this text
to make that more clear.  ``Directly passed'' is confusing, since
nothing is really passed anywhere.

Finally, our standard is to have 2 spaces after the period that ends a
sentence.  Please make sure you do that in your patch.


  reply	other threads:[~2004-05-18  6:32 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-18  2:47 Joel Brobecker
2004-05-18  6:32 ` Eli Zaretskii [this message]
2004-05-18 17:05   ` Joel Brobecker
2004-05-18 18:42     ` Eli Zaretskii
2004-05-18 19:03       ` Andrew Cagney
2004-05-19  5:39         ` Eli Zaretskii
2004-05-18 19:22       ` Joel Brobecker
2004-05-18 21:47 ` Daniel Jacobowitz
2004-05-18 22:27   ` Joel Brobecker
2004-05-18 22:41     ` Daniel Jacobowitz
2004-05-19 15:36       ` Joel Brobecker
2004-05-19 15:42         ` Daniel Jacobowitz
2004-05-19 16:10           ` Joel Brobecker
2004-05-20  1:01           ` Joel Brobecker
2004-05-20  5:29             ` Eli Zaretskii
2004-05-20 13:46             ` Daniel Jacobowitz
2004-05-20 16:03               ` Joel Brobecker
2004-05-20 17:14                 ` Daniel Jacobowitz
2004-05-20 20:33                   ` Paul Gilliam
2004-05-20 22:12                   ` Joel Brobecker
2004-05-21  0:26                     ` Daniel Jacobowitz
2004-05-21  1:31                       ` Joel Brobecker
2004-05-24 22:24                         ` Daniel Jacobowitz
2004-05-24 23:57                           ` Joel Brobecker
2004-05-19 14:30 ` Andrew Cagney
2004-05-19 15:39   ` Joel Brobecker
2004-05-19 20:02     ` Eli Zaretskii
2004-05-21 18:57       ` Andrew Cagney
2004-05-18 19:30 Michael Elizabeth Chastain
2004-05-18 19:45 ` Joel Brobecker
2004-05-18 20:21 Michael Elizabeth Chastain

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=6480-Tue18May2004093016+0300-eliz@gnu.org \
    --to=eliz@gnu.org \
    --cc=brobecker@gnat.com \
    --cc=gdb-patches@sources.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