This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: [PATCH 0/4] 'catch syscall' feature
- From: Sérgio Durigan Júnior <sergiodj at linux dot vnet dot ibm dot com>
- To: Phil Muldoon <pmuldoon at redhat dot com>
- Cc: Project Archer <archer at sourceware dot org>
- Date: Mon, 13 Oct 2008 14:21:57 -0200
- Subject: Re: [PATCH 0/4] 'catch syscall' feature
- Organization: LTC - IBM
- References: <1222799256.30389.31.camel@miki> <48F3389E.6060103@redhat.com>
Hi Phil,
On Mon, 2008-10-13 at 13:01 +0100, Phil Muldoon wrote:
> I looked at this patch, it looks great. Beyond the comments that others
> have added I have only a few small nitpick comments. As I cannot run
> this patch on my architecture, I'll have to guess a bit. What happens if
> a user attempts to use it without specific architecture support? What
> error message is written? The code that sets the breakpoint is:
Thanks for the comments. Your point is something that I've been
wondering since I've sent the patch. Well, your idea of puting a "gate"
in the syscall catchpoint creation is exactly what I was thinking about.
I think that I can use the gdbarch_syscall_number_from_name_p() to check
if syscalls catchpoints are enabled, and if this predicate returns NULL
then I assume that the architecture still doesn't support the feature.
What do you think? Do you have a better idea?
> The other thing is, is this test included in the patch only gated to run
> on Linux architectures that have syscall support added into GDB?
I'm afraid not, but I'm not sure. When I wrote the testcase, I didn't
know how to make this "gate"... I'll have to investigate it.
Well, thanks a lot for the comments :-).
Regards,
--
Sérgio Durigan Júnior
Linux on Power Toolchain - Software Engineer
Linux Technology Center - LTC
IBM Brazil