From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sourceware.org
Subject: Re: [RFA] Improve performance with lots of shared libraries
Date: Fri, 01 Jul 2011 17:32:00 -0000 [thread overview]
Message-ID: <20110701173233.GH2407@adacore.com> (raw)
In-Reply-To: <20110701165109.GA3399@redhat.com>
> 2011-07-01 Gary Benson <gbenson@redhat.com>
>
> * infrun.c (solib_event_breakpoint_helper_arg): New structure.
> (at_solib_event_breakpoint_helper): New function.
> (at_solib_event_breakpoint): Likewise.
> (handle_inferior_event): Avoid calling find_pc_partial_function
> and skip_inline_frames when stopping at the solib event breakpoint.
I just have a few general comments, that are minor, and yet important
(IMO).
> +/* Argument for at_solib_event_breakpoint_helper. */
> +
> +struct solib_event_breakpoint_helper_arg
> +{
> + CORE_ADDR prev_pc;
> + int shlib_bp_count;
> + int other_bp_count;
I think the meaning of each field should be documented. A good
example you could look at, for instance, is the declaration of
type struct frame_id in frame.h.
> +/* Helper for at_solib_event_breakpoint. */
I think it's important to also say WHAT the function does.
'Helper' doesn't help in that respect (no pun intended).
> +static int
> +at_solib_event_breakpoint (struct execution_control_state *ecs)
> +{
> + struct solib_event_breakpoint_helper_arg arg;
> + arg.prev_pc = ecs->event_thread->prev_pc;
> + arg.shlib_bp_count = arg.other_bp_count = 0;
Empty line between variable declarations and code...
(sorry, one of the innumerable coding style rules in the GDB project).
--
Joel
next prev parent reply other threads:[~2011-07-01 17:32 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-01 16:51 Gary Benson
2011-07-01 17:19 ` Tom Tromey
2011-07-04 14:10 ` Gary Benson
2011-07-01 17:32 ` Joel Brobecker [this message]
2011-07-04 14:21 ` Gary Benson
2011-07-01 17:45 ` Pedro Alves
2011-07-01 17:57 ` Pedro Alves
2011-09-09 14:25 Gary Benson
2011-09-09 14:35 ` Daniel Jacobowitz
2011-09-09 14:51 ` Jan Kratochvil
2011-09-09 15:04 ` Pedro Alves
2011-09-09 19:41 ` Jan Kratochvil
2011-09-12 12:44 ` Pedro Alves
2011-09-12 16:44 ` Jan Kratochvil
2011-09-14 9:28 ` Gary Benson
2011-10-04 19:46 ` Tom Tromey
2011-09-09 15:11 ` Pedro Alves
2011-09-09 14:53 ` Jan Kratochvil
2011-10-04 20:03 ` Tom Tromey
2011-09-22 17:35 Gary Benson
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=20110701173233.GH2407@adacore.com \
--to=brobecker@adacore.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