From: Joel Brobecker <brobecker@gnat.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA/RFC] New command: ``start''
Date: Tue, 18 May 2004 17:05:00 -0000 [thread overview]
Message-ID: <20040518170517.GF31800@gnat.com> (raw)
In-Reply-To: <6480-Tue18May2004093016+0300-eliz@gnu.org>
Eli,
Thanks for your useful comments. Attached are a couple of revised
patches based on your input.
> > 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.
OK. So I defined a new procedure in language.h, that returns a strdup
of "main". That way, all languages use the same approach, rather than
having only a few language having a non-null main_procedure_name
language method. Nice and consistent.
Just one additional comment, that may not be obvious: In Ada, the name
of the main procedure is not specified by Ada, it's up to the user to
choose it. That means that the name of that main procedure depends on
the program. When Ada-support is activated, we'll implement our own
main_procedure_name method that will dig out that name from the
executable. JIC.
> If we use "main" when the method is NULL, we should also use "main"
> if the method returns NULL, I think.
I changed the implementation to force the method to be defined.
I prefer that we report an error when the method failed to find the
name of the main procedure, rather than silently stop in start.
> > + 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.
Fixed. I also modified the description in an attempt to clarify how
arguments to this function are used.
> Please use "C@t{++}" instead of "C++", the former looks prettier in
> print.
Fixed.
> > +@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.
Fixed.
> > +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}".
Fixed. I also put the `start' in @samp, for consistency. I hope it was
the right thing to do.
> > 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?
I tried to make it more explanatory by explaining what happens during
the elaboration (some code is run before the main procedure is called),
and also by providing an example using C++ constructors.
> > +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.
I have reworked the documentation. Is it better?
I was also wondering whether it would be better to switch para 1 and 2.
That way, the user immediately knows what this command does. He then
gets the explanation of what the "main procedure" is.
> Finally, our standard is to have 2 spaces after the period that ends a
> sentence. Please make sure you do that in your patch.
Ouch! Sorry about that. I should know this by now, but I don't have
the reflex to remember it for the docs yet.
2004-05-17 Joel Brobecker <brobecker@gnat.com>
* language.h (language_defn): New field, la_xmain_procedure_name.
(xdefault_main_program_name): Add declaration.
* language.c (xdefault_main_program_name): New function.
(unknown_language_defn): Set new field to xdefault_main_program_name.
(auto_language_defn): Likewise.
(local_language_defn): Likewise.
* ada-lang.c (ada_language_defn): Likewise.
* c-lang.c (c_language_defn): Likewise.
(cplus_language_defn): Likewise.
(asm_language_defn): Likewise.
(minimal_language): Likewise.
* f-lang.c (f_language_defn): Likewise.
* jv-lang.c (java_language_defn): Likewise.
* m2-lang.c (m2_language_defn): Likewise.
* objc_language (objc_language_defn): Likewise.
* p-lang.c (pascal_language_defn): Likewise.
* scm-lang.c (scm_language_defn): Likewise.
* infcmd.c (kill_if_already_running): New function, extracted
from run_command().
(run_command): Replace extracted code by call to
kill_if_already_running().
(start_command): New function.
(_initialize_infcmd): Add "start" command.
2004-05-17 Joel Brobecker <brobecker@gnat.com>
* gdb.texinfo (Starting): Document new start command.
--
Joel
Attachment:
start_cmd.diff
Description: Text document
Attachment:
start_doc.diff
Description: Text document
next prev parent reply other threads:[~2004-05-18 17:05 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
2004-05-18 17:05 ` Joel Brobecker [this message]
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=20040518170517.GF31800@gnat.com \
--to=brobecker@gnat.com \
--cc=eliz@gnu.org \
--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