From: Eli Zaretskii <eliz@gnu.org>
To: "Sérgio Durigan Júnior" <sergiodj@linux.vnet.ibm.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 1/4] 'catch syscall' feature -- Architecture-independent part
Date: Tue, 04 Nov 2008 21:13:00 -0000 [thread overview]
Message-ID: <ubpwvureh.fsf@gnu.org> (raw)
In-Reply-To: <1225773079.24532.52.camel@miki>
> From: =?ISO-8859-1?Q?S=E9rgio?= Durigan =?ISO-8859-1?Q?J=FAnior?= <sergiodj@linux.vnet.ibm.com>
> Date: Tue, 04 Nov 2008 02:31:19 -0200
Thanks, but I cannot say I like the non-portable assumptions of this
design. For example:
> +void
> +clear_syscall_catchpoints_info (void)
> +{
> + struct breakpoint *b;
> +
> + ALL_BREAKPOINTS (b)
> + if (syscall_catchpoint_p (b))
> + b->syscall_number = UNKNOWN_SYSCALL;
> +} ^^^^^^^^^^^^^^^^^
Who said that a syscall is necessarily defined by some number?
More generally, let's say I'd like to implement support for this on
Windows -- how would I need to go about it?
> + /* We are in a entry breakpoint. */
> + entry_breakpoint,
> +
This comment is too obscure, IMO. Please make it more explicit; I
think you want to say that it's an entry to a syscall, right?
> + const char *syscall_name =
> + gdbarch_syscall_name_from_number (current_gdbarch, b->syscall_number);
Does this mean the notion that a syscall is a number have crept into
gdbarch, which is supposed to be the most architecture-independent
part of GDB?
> + /* Checking if the user provided a syscall name or a number. */
> + if (isdigit (cur_name[0]))
Is the assumption that no name will ever begin with a digit
universally valid?
> + error (_("The number '%d' does not represent a valid syscall."),
^^^^^^^^^^^^^^^
"a known syscall", I'd say.
> + if (syscall_number == UNKNOWN_SYSCALL)
> + error (_("Invalid syscall name '%s'."), cur_name);
^^^^^^^
"Unknown" is more accurate.
> static void
> @@ -7441,6 +7792,7 @@ delete_command (char *arg, int from_tty)
> b->type != bp_shlib_event &&
> b->type != bp_thread_event &&
> b->type != bp_overlay_event &&
> + b->type != bp_entry_breakpoint &&
The previous lines used TABs and spaces for indentation, while your
line uses only spaces.
> + add_catch_command ("syscall", _("\
> +Catch calls to syscalls.\n\
"call to syscalls" is awkward. I suggest to drop the "calls to" part.
> +With an argument, catch only calls of that syscall."),
Ditto, suggest to drop the "calls of" part.
> + add_setshow_filename_cmd ("gdb_datadir", class_maintenance,
> + &gdb_datadir, _("Set GDB's datadir path."),
> + _("Show GDB's datadir path."),
> + _("\
> +When set, GDB uses the specified path to search for data files."),
> + NULL, NULL,
> + &maintenance_set_cmdlist,
> + &maintenance_show_cmdlist);
This should be described in the manual.
next prev parent reply other threads:[~2008-11-04 21:13 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-04 4:32 Sérgio Durigan Júnior
2008-11-04 16:17 ` Pedro Alves
2008-11-07 3:30 ` Sérgio Durigan Júnior
2008-11-07 12:12 ` Pedro Alves
2008-11-07 13:30 ` Daniel Jacobowitz
2008-11-08 15:35 ` Sérgio Durigan Júnior
2008-11-04 17:57 ` Tom Tromey
2008-11-04 21:55 ` Thiago Jung Bauermann
2008-11-04 22:33 ` Tom Tromey
2008-11-05 19:05 ` Tom Tromey
2008-11-05 19:13 ` Sérgio Durigan Júnior
2008-11-07 3:41 ` Sérgio Durigan Júnior
2008-11-07 3:39 ` Sérgio Durigan Júnior
2008-11-07 18:21 ` Tom Tromey
2008-11-04 21:13 ` Eli Zaretskii [this message]
2008-11-04 22:12 ` Thiago Jung Bauermann
2008-11-04 22:22 ` Eli Zaretskii
2008-11-04 22:35 ` Daniel Jacobowitz
2008-11-05 4:19 ` Eli Zaretskii
2008-11-05 13:34 ` Sérgio Durigan Júnior
2008-11-05 18:42 ` Eli Zaretskii
2008-11-08 19:31 ` Mark Kettenis
2008-11-05 14:55 ` Daniel Jacobowitz
2008-11-05 18:43 ` Eli Zaretskii
2008-11-05 18:59 ` Daniel Jacobowitz
2008-11-05 19:11 ` Eli Zaretskii
2008-11-06 23:03 ` Mark Kettenis
2008-11-04 22:31 ` Pedro Alves
2008-11-05 4:10 ` Eli Zaretskii
2008-11-05 12:29 ` Pedro Alves
2008-11-05 18:38 ` Eli Zaretskii
2008-11-05 18:57 ` Pedro Alves
2008-11-05 19:10 ` Eli Zaretskii
2008-11-05 19:34 ` Pedro Alves
2008-11-05 20:36 ` Eli Zaretskii
2008-11-05 21:10 ` Pedro Alves
2008-11-06 4:27 ` Eli Zaretskii
2008-11-06 14:32 ` Pedro Alves
2008-11-07 9:59 ` Eli Zaretskii
2008-11-07 10:10 ` Pedro Alves
2008-11-05 13:32 ` Mark Kettenis
-- strict thread matches above, loose matches on Subject: below --
2008-09-30 18:12 Sérgio Durigan Júnior
2008-10-02 21:13 ` Joel Brobecker
2008-10-03 2:33 ` Sérgio Durigan Júnior
2008-10-03 6:07 ` Joel Brobecker
2008-10-03 17:52 ` Daniel Jacobowitz
2008-10-04 23:07 ` Sérgio Durigan Júnior
2008-10-04 23:04 ` Sérgio Durigan Júnior
2008-10-06 17:22 ` Joel Brobecker
2008-10-10 13:12 ` Daniel Jacobowitz
2008-10-10 15:28 ` Sérgio Durigan Júnior
2008-10-12 2:26 ` Sérgio Durigan Júnior
2008-10-15 5:40 ` Joel Brobecker
2008-10-16 3:35 ` Sérgio Durigan Júnior
2008-10-16 12:37 ` Daniel Jacobowitz
2008-10-16 15:17 ` Daniel Jacobowitz
2008-10-16 16:28 ` Joel Brobecker
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=ubpwvureh.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=sergiodj@linux.vnet.ibm.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