Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Justin Lebar <justin.lebar@gmail.com>
To: Tom Tromey <tromey@redhat.com>
Cc: Doug Evans <dje@google.com>, Stan Shebs <stanshebs@earthlink.net>,
	gdb-patches@sourceware.org
Subject: Re: Status of 'blacklist' patch?
Date: Tue, 25 Oct 2011 20:07:00 -0000	[thread overview]
Message-ID: <CAFWcpZ4gYFBeSeQcbB3icikcOJecOq+qBZXiza+zFjagDop3tQ@mail.gmail.com> (raw)
In-Reply-To: <m3r527mp9x.fsf@fleche.redhat.com>

> Justin> +  if (arg != 0)
> Justin> +    {
> Justin> +      entry_num = parse_and_eval_long (arg);
> Justin> +    }
>
> This will parse and evaluate an expression.  I think something like what
> "info break" does would be more in keeping with other places in gdb --
> that is, use get_number_or_range, then iterate.

breakpoint_1 calls parse_and_eval_long:

	  if (allflag && parse_and_eval_long (args) != b->number)
	    continue;
	  if (!allflag && !number_is_in_list (args, b->number))
	    continue;

Do we want to copy the breakpoint code here, or not?

On Thu, Oct 20, 2011 at 3:33 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Justin" == Justin Lebar <justin.lebar@gmail.com> writes:
>
> Justin> Added a NEWS entry in this patch.
>
> Thanks.
>
> I think this still needs a doc review.
>
> Some review below.  I think this patch is pretty close to being ready;
> and I am eager for it to go in.
>
> Justin> +  /* null if this isn't a skiplist entry for an entire file.
>
> "NULL"
>
> Justin> +     The skiplist entry owns this pointer. */
>
> In our style, sentences have 2 spaces after the period.
>
> Justin> +//static void try_resolve_pending_entry (struct skiplist_entry *e);
>
> We can't use "//" comments in gdb, but I think there's really no reason
> for a new file to have commented-out code.
>
> Justin> +      TRY_CATCH(decode_exception, NOT_FOUND_ERROR)
>
> Space before the open paren.
>
> Justin> +  if (arg != 0)
> Justin> +    {
> Justin> +      entry_num = parse_and_eval_long (arg);
> Justin> +    }
>
> This will parse and evaluate an expression.  I think something like what
> "info break" does would be more in keeping with other places in gdb --
> that is, use get_number_or_range, then iterate.
>
> Justin> +      entry_chain = make_cleanup_ui_out_tuple_begin_end (current_uiout, "blklst-entry");
>
> I think this line is too long.
> Maybe a few others in this function, too.
>
> Justin> +static void
> Justin> +skip_enable_command (char *arg, int from_tty)
> Justin> +{
> Justin> +  struct skiplist_entry *e;
> Justin> +  int entry_num;
> Justin> +  if (arg == 0)
>
> Newline after the declaration block, here and elsewhere.
>
> Justin> +  entry_num = parse_and_eval_long (arg);
>
> This command and others should use get_number_or_range.
>
> Justin> +      ALL_SKIPLIST_ENTRIES_SAFE(e, temp)
>
> Space before open paren.
>
> Justin> +  ALL_SKIPLIST_ENTRIES (e)
> Justin> +    {
> Justin> +      int pc_match = e->pc != 0 && pc == e->pc;
> Justin> +      int filename_match = e->filename != 0 && filename != 0 &&
>
> You have to parenthesize the RHS according to GNU standards, and put the
> "&&" at the start of the second line.
>
> Justin> +                          strcmp (filename, e->filename) == 0;
> Justin> +      if (e->enabled && !e->pending && (pc_match || filename_match))
> Justin> +       return 1;
>
> I think you could check enabled and pending earlier and avoid the strcmp
> unless truly needed.
>
> Also I think it would be worthwhile to lazily compute the SAL in this
> function, to avoid computing it at all when there are no (or no enabled)
> skip entries.
>
> Justin> +void
> Justin> +skip_re_set ()
>
> Should be '(void)'
>
> Justin> +         TRY_CATCH(decode_exception, NOT_FOUND_ERROR)
>
> Space before paren.
>
> Justin> +         if (decode_exception.reason >= 0 &&
>
> "&&" on next line.
>
> Justin> +                  e->function_name = xstrdup(func_name);
>
> Space before paren.
>
> Justin> +/* Helper function to get a gdbarch from a symtab_and_line. */
> Justin> +static struct gdbarch*
> Justin> +get_sal_arch (struct symtab_and_line *sal)
> Justin> +{
> Justin> +  if (sal->section)
> Justin> +    return get_objfile_arch (sal->section->objfile);
> Justin> +  if (sal->symtab)
> Justin> +    return get_objfile_arch (sal->symtab->objfile);
> Justin> +  return get_current_arch ();
> Justin> +}
>
> I think it is better to make this public in breakpoint.c.
>
> Really, we should probably have a "sal.h" and "sal.c" and treat it like
> a real data structure.  Not your job though.
>
> Justin> +  add_prefix_cmd ("skip", class_breakpoint, skip_function_command, _("\
> Justin> +Ignore a function while stepping.\n\
> Justin> +skip [FUNCTION NAME]\n\
>
> I'd like this line to start with "Usage: " (and likewise in the other
> help text).
>
> Justin> +void skip_re_set ();
>
> Should be '(void)'.
>
> Justin> +struct program_space*
> Justin> +get_last_displayed_pspace ()
>
> Space before "*".
> "(void)", here and elsewhere.
>
> Most of the functions around this need introductory comments.
>
> Justin> +void clear_last_displayed_sal ();
> Justin> +int last_displayed_sal_is_valid ();
> Justin> +struct program_space* get_last_displayed_pspace ();
> Justin> +CORE_ADDR get_last_displayed_addr ();
> Justin> +struct symtab* get_last_displayed_symtab ();
> Justin> +int get_last_displayed_line ();
>
> "(void)" for all of these.
>
> Tom
>


  reply	other threads:[~2011-10-25 19:52 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-06 12:12 Diego Novillo
2011-10-06 14:08 ` Justin Lebar
2011-10-06 15:51   ` Stan Shebs
2011-10-06 20:16     ` Justin Lebar
2011-10-10 12:34       ` Stan Shebs
2011-10-11 21:34         ` Justin Lebar
2011-10-11 23:54           ` Doug Evans
2011-10-16 19:22             ` Justin Lebar
2011-10-20 19:46               ` Tom Tromey
2011-10-25 20:07                 ` Justin Lebar [this message]
2011-10-25 20:41                   ` Pedro Alves
2011-10-25 21:25                     ` Justin Lebar
2011-10-20 20:40               ` Eli Zaretskii
2011-10-25 16:47                 ` Justin Lebar
2011-10-25 16:53                   ` Eli Zaretskii
2011-10-25 19:52                     ` Justin Lebar
2011-10-25 20:13                       ` Eli Zaretskii
2011-10-25 20:30                         ` Justin Lebar
2011-10-26  1:06                           ` Stan Shebs
2011-10-26  3:45                             ` Justin Lebar
2011-10-26  5:37                               ` Stan Shebs
2011-10-26  8:10                                 ` Joel Brobecker
2011-10-26 13:28                             ` Eli Zaretskii
2011-10-26 15:11                               ` Justin Lebar
2011-10-28 18:18                                 ` Tom Tromey
2011-10-28 19:48                                   ` Justin Lebar
2011-10-28 19:53                                     ` Tom Tromey
2011-10-28 19:49                                 ` Tom Tromey
2011-10-28 19:55                                   ` Justin Lebar
2011-10-28 20:37                                     ` Tom Tromey
2011-10-31 15:52                                       ` Justin Lebar
     [not found]                                         ` <4EAF2E0E.7080508@earthlink.net>
2011-11-01 14:53                                           ` Justin Lebar
2011-11-02 22:43                                             ` Maciej W. Rozycki
2011-11-02 23:52                                               ` Stan Shebs
2011-11-03  0:20                                                 ` Maciej W. Rozycki
2011-11-03  3:54                                               ` Eli Zaretskii
2011-11-03 14:32                                                 ` Tom Tromey
2011-11-03 16:54                                                   ` Eli Zaretskii
2011-11-03 18:04                                                   ` Maciej W. Rozycki
2011-11-03 18:25                                                     ` Eli Zaretskii
2011-11-03 19:01                                                       ` Stan Shebs
2011-10-06 17:19   ` Diego Novillo
2011-10-06 17:33   ` Tom Tromey
2011-10-06 17:37     ` Diego Novillo

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=CAFWcpZ4gYFBeSeQcbB3icikcOJecOq+qBZXiza+zFjagDop3tQ@mail.gmail.com \
    --to=justin.lebar@gmail.com \
    --cc=dje@google.com \
    --cc=gdb-patches@sourceware.org \
    --cc=stanshebs@earthlink.net \
    --cc=tromey@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