Re: [PATCH] Improve and fix catch-syscall.exp

[Doug Evans <xdje42@gmail.com>]

On Sun, Dec 15, 2013 at 10:30 AM, Doug Evans <xdje42@gmail.com> wrote:
> Sergio Durigan Junior <sergiodj@redhat.com> writes:
>
>> Hi,
>>
>> While fixing another bug, I found that the current
>> gdb.base/catch-syscall.exp is kind of messy, could use some
>> improvements, and is not correctly testing some things.
>>
>> I've made the following patch to address all the issues I found.  On the
>> organization side, it does a cleanup and removes unecessary imports of
>> gdb_prompt, uses prepare_for_testing and clean_restart where needed, and
>> fixes some comments.  The testcase was also not correctly testing
>> catching syscalls using only numbers, or catching many syscalls at
>> once.  I fixed that.  This is good because I will soon submit another
>> patch to fix a bug on catch syscall which will make use of the new
>> things I've added.
>>
>> I tested this on x86_64 Fedora 18, and I'm waiting for machines to test
>> on PPC and ARM at least, but I checked the syscalls numbers on every
>> architecture supported by the patch to make sure everything was OK.
>>
>> OK to apply?
>
> Hi.
>
> I was wondering, what if the magic numbers that are the syscall
> numbers were recorded in the test .c file like:
>
> int close_syscall_number = foo;
>
> and then have the .exp fetch these values after running-to-main.
> That would save having to record syscall numbers in the .exp,
> and all the conditionals to test for the architecture.
>
> Not sure there isn't a flaw in this plan,
> and I guess it's debatable whether it's better to just record
> the numbers in the .exp or reference the __NR_* numbers from asm/unistd*.h
> in the .c, but it sounds promising.

Alternatively, gdb knows the numbers.  IWBN to provide a way to print
them, and then the .exp file could get the numbers from that.
OTOH, one could just have the .exp do the catch and process the output
to get the number.

(gdb) catch syscall 6
Catchpoint 2 (syscall 'close' [6])
(gdb) catch syscall close
Catchpoint 1 (syscall 'close' [6])

One might even check the .c __NR_ value with gdb's value computed from
the .exp for extra paranoid testing, but I'm guessing there's
insufficient benefit.