Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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 (&current_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


  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