From: "Sérgio Durigan Júnior" <sergiodj@linux.vnet.ibm.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 1/4] 'catch syscall' feature -- Architecture-independent part
Date: Fri, 03 Oct 2008 02:33:00 -0000 [thread overview]
Message-ID: <1223001252.9858.11.camel@miki> (raw)
In-Reply-To: <20081002211256.GO3665@adacore.com>
Hi Joel,
On Thu, 2008-10-02 at 14:12 -0700, Joel Brobecker wrote:
> > * breakpoint.h (enum bptype): Add syscall catchpoint and entry
> > breakpoint types.
> > (struct breakpoint): Add field 'syscall_number' (used to know
> > which syscall triggered the catchpoint) and
> > 'syscall_to_be_caught' (used to know which syscall we are trying
> > to catch).
>
> I would really like to try to avoid creating a different enum for
> each catchpoint type, if we can. See for instance how I implemented
> Ada exception catchpoints:
>
> http://www.sourceware.org/ml/gdb-patches/2007-01/msg00102.html
>
> Do you think we could leverage on the "breakpoint_ops" structure
> to implement this feature? Daniel, you know this part of the code
> really well, what do you think?
>
> Obviously, his feature is a different kind of beast than Ada exception
> catchpoints (which behind the scene is just an elaborated breakpoint).
> So he won't be able to use the bp_breakpoint kind I used. Actually,
> I don't see any bptype kind that could be used, so we'll have to create
> one, but if the name could be generic enough to be used in other
> circumstances.
If I understood correctly, you think it's better to create a "generic"
bptype so that not only "catch syscall" can use it, right? That, or
figure out some other way to use "breakpoint_ops" in order to identify
if the catchpoint is a syscall one. Is it?
The way I see, there's no problem to implement "catch syscall" using
another way. However, and I think you already know that, the "catch
fork", "catch vfork" and "catch exec" are implemented using an entry on
"enum bptype" (and that's specific why I've chosen to do this). Do you
think we should change this, too?
> Similarly, the breakpoint_ops structure might need to be extended
> a bit, to provide methods that would insert/remove the catchpoint.
I'm not sure if I understood this part correctly. Maybe my GDB-fu isn't
good enought yet :-). I'll take a look at breakpoint_ops to see if I can
understand better what you want.
Thanks for the review, by the way.
Regards,
--
Sérgio Durigan Júnior
Linux on Power Toolchain - Software Engineer
Linux Technology Center - LTC
IBM Brazil
next prev parent reply other threads:[~2008-10-03 2:33 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
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
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
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=1223001252.9858.11.camel@miki \
--to=sergiodj@linux.vnet.ibm.com \
--cc=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