Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Sergio Durigan Junior <sergiodj@redhat.com>
To: gdb-patches@sourceware.org
Subject: Re: [RFA] Improved linker-debugger interface
Date: Sat, 05 May 2012 04:39:00 -0000	[thread overview]
Message-ID: <m37gwrs0m6.fsf@redhat.com> (raw)
In-Reply-To: <20120504152129.GA7418@redhat.com> (Gary Benson's message of	"Fri, 4 May 2012 16:21:29 +0100")

On Friday, May 04 2012, Gary Benson wrote:

> Hi all,

Hi Gary,

Thanks for the patch.  Nice to see the SystemTap patch is useful :-).

I glanced over the code, but saw a few minor nits.

> diff --git a/gdb/infrun.c b/gdb/infrun.c
> index ab51806..0f099cf 100644
> --- a/gdb/infrun.c
> +++ b/gdb/infrun.c
> @@ -361,6 +361,13 @@ static struct symbol *step_start_function;
>  /* Nonzero if we want to give control to the user when we're notified
>     of shared library events by the dynamic linker.  */
>  int stop_on_solib_events;
> +
> +static void
> +set_stop_on_solib_events (char *args, int from_tty, struct cmd_list_element *c)
> +{
> +  update_solib_breakpoints ();
> +} 
> +

This function needs a comment.

> diff --git a/gdb/solib-svr4.c b/gdb/solib-svr4.c
> index 69d3cb5..4897d51 100644
> --- a/gdb/solib-svr4.c
> +++ b/gdb/solib-svr4.c
> @@ -47,6 +47,8 @@
>  #include "auxv.h"
>  #include "exceptions.h"
>  
> +#include "stap-probe.h"

You don't need to include `stap-probe.h' here, just `probe.h'.
`stap-probe.h' contains only a definition of a structure which is useful
for per-arch parsing of probes' arguments.

> @@ -92,6 +94,32 @@ static const char * const solib_break_names[] =
>    NULL
>  };
>  
> +/* A list of SystemTap probes which, if present in the dynamic linker,
> +   allow more fine-grained breakpoints to be placed on shared library
> +   events.  */
> +
> +struct probe_info
> +  {
> +    /* The name of the probe.  */
> +    const char *name;
> +
> +    /* Nonzero if this probe must be stopped at even when
> +       stop-on-solib-events is off.  */
> +    int mandatory;

I don't know what others think about it, but the `mandatory' flag can be
a bitfield, like this:

  int mandatory_p : 1;

Also, since this is a predicate to indicate whether or not something
happens, it's better to put the `_p' suffix.

> +  };
> +
> +static const struct probe_info probe_info[] =
> +{
> +  {"rtld_init_start", 0},
> +  {"rtld_init_complete", 1},
> +  {"rtld_map_start", 0},
> +  {"rtld_reloc_complete", 1},
> +  {"rtld_unmap_start", 0},
> +  {"rtld_unmap_complete", 1},
> +};

This should also have a comment.

The brackets should be indented like this:

struct foo bar[] =
  {
    { "bla", 0 },
    ...
  };

Also, I think it's more legible when you put a space between the open
bracket and the "bla", like I did above.


> +
>  static const char * const bkpt_names[] =
>  {
>    "_start",
> @@ -313,6 +341,12 @@ struct svr4_info
>    CORE_ADDR interp_text_sect_high;
>    CORE_ADDR interp_plt_sect_low;
>    CORE_ADDR interp_plt_sect_high;
> +
> +  /* SystemTap probes.  */
> +  VEC (probe_p) *probes[NUM_PROBES];
> +
> +  /* Nonzero if we are using the SystemTap interface.  */
> +  int using_probes;

Same comment regarding using bitfield, but I'd like to hear what others
think about it.

This should also contain the `_p' suffix.

Also, I've been thinking about creating some predicate that would
confirm if some probe is of certain type of not.  The way it is today,
when you call `find_probes_in_objfile', there's no way to confirm that
the probes are SystemTap probes (obviously, today SystemTap probes are
the only allowed/implemented types of probes that use this backend, but
still...).

> diff --git a/gdb/solib.c b/gdb/solib.c
> index 656e8df..57f6c1a 100644
> --- a/gdb/solib.c
> +++ b/gdb/solib.c
> @@ -1211,6 +1211,18 @@ no_shared_libraries (char *ignored, int from_tty)
>    objfile_purge_solibs ();
>  }
>  
> +/* Enable or disable optional solib event breakpoints as appropriate.  */
> +
> +void
> +update_solib_breakpoints (void)
> +{
> +  struct target_so_ops *ops = solib_ops (target_gdbarch);
> +
> +  if (ops->update_breakpoints != NULL)
> +    ops->update_breakpoints ();
> +}
> +  
> +
>  /* Reload shared libraries, but avoid reloading the same symbol file
>     we already have loaded.  */
>  
> diff --git a/gdb/solib.h b/gdb/solib.h
> index 7a2ff84..65e3857 100644
> --- a/gdb/solib.h
> +++ b/gdb/solib.h
> @@ -91,4 +91,8 @@ extern CORE_ADDR gdb_bfd_lookup_symbol_from_symtab (bfd *abfd,
>  								      void *),
>  						    void *data);
>  
> +/* Enable or disable optional solib event breakpoints as appropriate.  */
> +
> +extern void update_solib_breakpoints (void);

This comment should be either on the header file, or on the definition
of the function, but not on both, I think.  I prefer comments on the
header file.

Again, thanks for the patch :-).

-- 
Sergio


  reply	other threads:[~2012-05-05  4:39 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-04 15:22 Gary Benson
2012-05-05  4:39 ` Sergio Durigan Junior [this message]
2012-05-05  6:03   ` Jan Kratochvil
2012-05-05  6:11     ` Sergio Durigan Junior
2012-05-05  6:23       ` Jan Kratochvil
2012-05-07 16:57 ` Jan Kratochvil
2012-05-07 17:51   ` Sergio Durigan Junior
2012-05-07 20:27   ` Tom Tromey
2012-05-07 21:32     ` Mark Kettenis
2012-05-07 21:44       ` Jan Kratochvil
2012-05-08  5:45       ` Sergio Durigan Junior
2012-05-08 13:37       ` Tom Tromey
2012-05-09  8:12         ` Mark Kettenis
2012-05-09 15:57           ` Tom Tromey

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=m37gwrs0m6.fsf@redhat.com \
    --to=sergiodj@redhat.com \
    --cc=gdb-patches@sourceware.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