Re: [PATCH 0/4] 'catch syscall' feature

[Phil Muldoon <pmuldoon at redhat dot com>]

Sérgio Durigan Júnior wrote:
> 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?
>
>   

Yeah my real only concern is that somebody might - on their unsupported 
architecture - try to catch a syscall, and in the current code GDB might 
report that the syscall does not exist. This just "sounds" incorrect. 
I'll have to have a look at how GDB "gates" this kind of functionality 
around other features/architectures. Maybe it doesn't.

> > 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.
>
>   

A lot of checking for target functionality goes on in 
testsuite/lib/gdb.exp. A specific case I am familiar with (and I 
borrowed for my own test-case) was this scenario:

+ # Some targets can't do function calls, so don't even bother with this
+ # test.
+ if [target_info exists gdb,cannot_call_functions] {
+    setup_xfail "*-*-*" 2416
+    fail "This target can not call functions"
+    continue
+ }

So maybe there is something already in the target_info data, or can be 
added. All I can provide is hints alas, as I've no idea if this info is 
already there, or has to be added.

Regards

Phil