public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Sergio Durigan Junior <sergiodj@redhat.com>
Cc: gdb-patches@sourceware.org, Tom Tromey <tromey@redhat.com>
Subject: Re: [RFC] Make static tracepoint with markers more OO
Date: Fri, 13 Jan 2012 11:14:00 -0000	[thread overview]
Message-ID: <4F1010F5.4020104@redhat.com> (raw)
In-Reply-To: <m362gg9ro7.fsf@gmail.com>

On 01/13/2012 04:01 AM, Sergio Durigan Junior wrote:
> Hello there,
> 
> I have been working on this patch, and I would like some comments from
> you guys.  It basically implements new methods inside breakpoint_ops in
> order to make static tracepoint with markers (`strace -m') more OO.

Thanks.

> Currently, we use a check (defined in `is_marker_spec') in order to
> identify those tracepoints, and act accordingly.  However, it makes the
> code (especially the functions `create_breakpoint' and
> `addr_string_to_sals') very conditional.
> 
> This would be OK if it were to be the only case, but as it turns out our
> SystemTap integration patch will have to add more complexity to this
> code, which would make things uglier and uglier.  So, as a preparation
> for the second round of submissions of the SystemTap patch, I am
> submitting this patch first.
> 
> I am not sure the names I picked for the new methods are good.  I had
> spent a good time thinking about the names, but unfortunately I couldn't
> come up with something better than this.  I am specially concerned about
> the `create_breakpoints_sal*' set of methods/functions, because there
> are too many of them IMO.  I would appreciate some reviews on the
> comments of the methods, as well.  I believe the separation is pretty
> straightforward, so I think this is just moving bits here and there
> without actually implementing anything new.
> 
> Comments are welcome, as usual.

This is fine with me.

> -/* Assuming we're creating a static tracepoint, does S look like a
> -   static tracepoint marker spec ("-m MARKER_ID")?  */
> -#define is_marker_spec(s)						\
> -  (s != NULL && strncmp (s, "-m", 2) == 0 && ((s)[2] == ' ' || (s)[2] == '\t'))
> +/* Return 1 if B refers to a static tracepoint marker, zero otherwise.  */

I think

 /* Return 1 if B refers to a static tracepoint set by marker ("-m"), zero otherwise.  */

would be clearer.

> +
> +static int strace_marker_p (struct breakpoint *b);


> -      if (b->type == bp_static_tracepoint && !marker_spec)
> +      if (strace_marker_p (b))

This one looks wrong.  The old condition had a `!', so this was for
static tracepoints _not_ set through a marker.

> +
> +  /* Create SALs from address string, storing the result in linespec_result.
> +     Return 1 on success, or zero otherwise.
> +
> +     For an explanation about the arguments, see the function
> +     `create_sals_from_address_default'.
> +
> +     This function is called inside `create_breakpoint'.  */
> +  int (*create_sals_from_address) (char **, struct linespec_result *,
> +				   enum bptype, int *, char *, char **);
> +
> +  /* This method will be responsible for creating a breakpoint given its SALs.
> +     Usually, it just calls `create_breakpoints_sal' (for ordinary
> +     breakpoints).  However, there may be some special cases where we might
> +     need to do some tweaks, e.g., see
> +     `strace_marker_init_or_create_breakpoint_sal'.
> +
> +     This function is called inside `create_breakpoint'.  */
> +  void (*create_breakpoints_sal) (struct gdbarch *,
> +				  struct linespec_result *,
> +				  struct linespec_sals *, char *,
> +				  enum bptype, enum bpdisp, int, int,
> +				  int, const struct breakpoint_ops *,
> +				  int, int, int);

It's unfortunate to be calling the breakpoint's virtual methods
before the object itself is created, which will require some redesign
and refactoring if we ever switch to C++ (and is dangerous, as you may
end up touching parts of the object which are not constructed yet by
mistake), but, this is no worse than what we have now, so I'm fine with it.

> +
> +  /* Given the address string (second parameter), this method decodes it
> +     and provides the SAL locations related to it.  For ordinary breakpoints,
> +     it calls `decode_line_full'.
> +
> +     This function is called inside `addr_string_to_sals'.  */
> +  void (*decode_linespec) (struct breakpoint *, char **,
> +			   struct symtabs_and_lines *);
>  };
>  
>  /* Helper for breakpoint_ops->print_recreate implementations.  Prints

  reply	other threads:[~2012-01-13 11:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-13  7:24 Sergio Durigan Junior
2012-01-13 11:14 ` Pedro Alves [this message]
2012-01-13 17:24   ` Sergio Durigan Junior
2012-01-16 12:32     ` Pedro Alves
2012-01-13 15:46 ` Tom Tromey
2012-01-13 23:49   ` Sergio Durigan Junior
2012-01-16 17:03     ` Tom Tromey
2012-01-16 17:10       ` Sergio Durigan Junior
2012-01-16 17:19         ` Pedro Alves
2012-01-16 19:29           ` Sergio Durigan Junior

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=4F1010F5.4020104@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=sergiodj@redhat.com \
    --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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).