From: Keith Seitz <keiths@redhat.com>
To: John Baldwin <jhb@FreeBSD.org>, gdb-patches@sourceware.org
Subject: Re: [PATCH] Add a 'starti' command.
Date: Wed, 30 Aug 2017 22:32:00 -0000 [thread overview]
Message-ID: <64d0abc2-4fb1-7624-9e13-2d28a6eb2bbf@redhat.com> (raw)
In-Reply-To: <20170829225457.66096-1-jhb@FreeBSD.org>
Hi,
I've looked over this patch, and I have a few small requests. [I am not a global maintainer and cannot officially approve your patch.]
On 08/29/2017 03:54 PM, John Baldwin wrote:
> This works like 'start' but it stops at the first instruction rather than
> the first line in main(). This is useful if one wants to single step
> through runtime linker startup.
I like this!
> diff --git a/gdb/infcmd.c b/gdb/infcmd.c
> index bd9ead8a45..5e9173ff44 100644
> --- a/gdb/infcmd.c
> +++ b/gdb/infcmd.c
> @@ -520,12 +520,14 @@ prepare_execution_command (struct target_ops *target, int background)
> }
> }
>
> +enum run_break { NONE, MAIN, FIRST_INSTR };
> +
This does not conform to our coding standard. We typically require a comment before the enum explaining its usage/purpose and additional comments explaining what each member means. Something like:
/* Determines how run_command_1 will behave. */
enum run_break
{
/* Run the inferior. */
NONE,
/* Run the inferior, stopping at the first instruction of main. */
MAIN,
// ...
};
While I would rather see these options be a little more succinctly named, such as RUN_NONE, RUN_STOP_MAIN, RUN_STOP_MAIN_FIRST_INSN, I'm not going to ask for that change. But please do consider it.
> /* Implement the "run" command. If TBREAK_AT_MAIN is set, then insert
> a temporary breakpoint at the begining of the main program before
> running the program. */
>
> static void
> -run_command_1 (char *args, int from_tty, int tbreak_at_main)
> +run_command_1 (char *args, int from_tty, enum run_break run_break)
The comment to this function needs updating: it still refers to the (removed) argument TBREAK_AT_MAIN and does not mention RUN_BREAK.
> {
> const char *exec_file;
> struct cleanup *old_chain;
> @@ -632,6 +634,14 @@ run_command_1 (char *args, int from_tty, int tbreak_at_main)
> has done its thing; now we are setting up the running program. */
> post_create_inferior (¤t_target, 0);
>
> + if (run_break == FIRST_INSTR)
> + {
> + gdb::unique_xmalloc_ptr<char> loc
> + (xstrdup (("*" + std::to_string (regcache_read_pc
> + (get_current_regcache ()))).c_str ()));
> + tbreak_command (loc.get (), 0);
> + }
> +
I understand why you did it this way, but I really think using create_breakpoint directly is a better option instead of routing through an existing CLI command (tbreak_command).
Something along the lines of:
CORE_ADDR insn = regcache_read_pc (get_current_regcache ());
event_location_up loc = new_address_location (insn, NULL, 0);
create_breakpoint (get_current_arch (), loc.get (),
NULL /* cond_string */, -1 /* thread */,
NULL /* extra_string */, 0 /* parse_extra */,
1 /* tempflag */, bp_breakpoint,
0 /* ignore_count */,
AUTO_BOOLEAN_FALSE /* pending_break_support */,
&bkpt_breakpoint_ops, from_tty, 1 /* enabled */,
0 /* internal */, 0 /* flags */);
> /* Start the target running. Do not use -1 continuation as it would skip
> breakpoint right at the entry point. */
> proceed (regcache_read_pc (get_current_regcache ()), GDB_SIGNAL_0);
> @@ -660,7 +670,17 @@ start_command (char *args, int from_tty)
> error (_("No symbol table loaded. Use the \"file\" command."));
>
> /* Run the program until reaching the main procedure... */
> - run_command_1 (args, from_tty, 1);
> + run_command_1 (args, from_tty, MAIN);
> +}
> +
> +/* Start the execution of the program until the first instruction. */
> +
> +static void
> +starti_command (char *args, int from_tty)
> +{
> +
> + /* Run the program until reaching the first instruction... */
> + run_command_1 (args, from_tty, FIRST_INSTR);
> }
I'm all for commenting code, but the comment describing the function is sufficient. :-)
> static int
> @@ -3415,6 +3435,12 @@ You may specify arguments to give to your program, just as with the\n\
> \"run\" command."));
> set_cmd_completer (c, filename_completer);
>
> + c = add_com ("starti", class_run, starti_command, _("\
> +Start the debugged program stopping at the first instruction.\n\
> +You may specify arguments to give to your program, just as with the\n\
> +\"run\" command."));
> + set_cmd_completer (c, filename_completer);
> +
> add_com ("interrupt", class_run, interrupt_command,
> _("Interrupt the execution of the debugged program.\n\
> If non-stop mode is enabled, interrupt only the current thread,\n\
>
I would take the common start/starti text and put it into a macro similar to the way the breakpoint commands are setup.
Alas the last thing missing is a test case for this. It doesn't have to be anything fancy, just check that with no breakpoints installed, starti will actually cause the inferior to stop somewhere/anywhere. [I don't think we can generically do much better than this, e.g., testing if we actually do stop at the first insn.]
Keith
next prev parent reply other threads:[~2017-08-30 22:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-29 22:55 John Baldwin
2017-08-30 14:14 ` Eli Zaretskii
2017-08-30 22:32 ` Keith Seitz [this message]
2017-08-31 21:51 ` Pedro Alves
2017-08-31 22:42 ` John Baldwin
2017-09-01 21:42 ` John Baldwin
2017-09-02 6:28 ` Ruslan Kabatsayev
2017-09-04 10:57 ` Pedro Alves
2017-09-11 22:08 ` John Baldwin
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=64d0abc2-4fb1-7624-9e13-2d28a6eb2bbf@redhat.com \
--to=keiths@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=jhb@FreeBSD.org \
/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