This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]