On 5/5/22 15:23, Simon Marchi wrote:
> On 2022-05-05 07:47, Tom de Vries via Gdb-patches wrote:
>> On 5/3/22 16:57, Tom de Vries wrote:
>>> Hi,
>>>
>>> When running test-case gdb.reverse/pipe-reverse.exp on openSUSE Tumbleweed,
>>> I run into:
>>> ...
>>> (gdb) continue^M
>>> Continuing.^M
>>> ^M
>>> Catchpoint 2 (returned from syscall pipe2), in pipe () from /lib64/libc.so.6^M
>>> (gdb) FAIL: gdb.base/catch-syscall.exp: without arguments: \
>>>     syscall pipe has returned
>>> ...
>>>
>>> The current glibc on Tumbleweed is 2.35, which contains commit
>>> "linux: Implement pipe in terms of __NR_pipe2", and consequently syscall pipe2
>>> is used in stead of syscall pipe.
>>>
>>> Fix this by detecting whether syscall pipe or pipe2 is used before running the tests.
>>>
>>> Tested on x86_64-linux, specifically on:
>>> - openSUSE Tumbleweed (with glibc 2.35), and
>>> - openSUSE Leap 15.3 (with glibc 2.31).
>>>
>>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29056
>>>
>>> Any comments?
>>>
>>
>> I'm submitting a v2.  I found out that with target board unix/-m32, pipe2 is not recognized as syscall name (which I'll fix in a follow-up patch), so I made the test robust against this, by using the syscall number instead.
>>
>> Thanks,
>> - Tom
>>
> 
> 
> I don't understand why we would want that fallback to use numbers.  If GDB doesn't
> know about pipe2 (like it does now), it's a GDB bug that needs to be fixed.  I don't
> see why we would want to adjust the test instead of fixing GDB.

There are two things tested here in conjunction in the test-case:
- whether gdb knowns the name of a syscall
- whether the syscall can be caught by gdb

Currently, if the test for the first part fails, we have no usable 
information on the second part.

I tried to make these things independently testable, with the idea that 
this makes the test give more information.  So, I'm not proposing to fix 
a test instead of fixing gdb.  I'm proposing to fix the test such that I 
can more precisely link a single FAIL -> PASS to a gdb fix.

It could be argued that the second part actually is the interesting 
part.  If gdb doesn't know the name of a syscall, a user can always 
lookup the number and use that instead.  But if there is a problem 
catching that syscall, the user cannot work around that, so that is good 
to know about.

But ok, perhaps I'm overthinking things here, and it does makes the 
test-case more complicated, so ... committed this version that only uses 
the name of the syscall.

Thanks,
- Tom