Re: [PATCH][PATCH] Update syscalls/{ppc64,ppc}-linux.xml

[Tom de Vries via Gdb-patches <gdb-patches@sourceware.org>]

On 5/10/22 20:02, Kevin Buettner wrote:
> On Tue, 10 May 2022 11:01:27 +0200
> Tom de Vries <tdevries@suse.de> wrote:
> 
>> On 5/9/22 17:48, Tom de Vries wrote:
>>> Hi,
>>>
>>> Regenerate syscalls/{ppc64,ppc}-linux.xml on a system with 5.14 kernel.
>>>
>>> Note btw that it does not only add, but also renumbers, f.i.:
>>> ...
>>> -  <syscall name="unlinkat" number="286"/>
>>> +  <syscall name="unlinkat" number="292"/>
>>> ...
>>>
>>> Currently testing.
>>>
>>
>> Here's a v2, with a gdb.base/catch-syscall.exp test-case fix included.
>>
>> Testing on ppc64le revealed:
>> ...
>> (gdb) catch syscall 286^M
>> Catchpoint 2 (syscall 'openat' [286])^M
>> (gdb) FAIL: gdb.base/catch-syscall.exp: multiple targets: insert catch
>> syscall on syscall 286\
>>    -- unlinkat on powerpc:common64
>> ...
>>
>> FWIW, I've wrote a patch that exposes the same problem on x86_64-linux (
>> https://sourceware.org/pipermail/gdb-patches/2022-May/188881.html ).
>>
>> Any comments?
> 
> I don't have a problem with your patch, which (mostly) updates system call
> numbers.
> 
> What I am wondering about is how often they change?  Also, what happens
> when a GDB with some set of syscall numbers is used with a kernel which
> uses different numbers?  (Nothing good, I'd guess.)  I'm just wondering
> if there's a better way to do things...

I've found here ( https://www.kernel.org/doc/Documentation/ABI/README ):
...
  Most interfaces (like syscalls) are expected to never change and always
  be available.
...

So I suppose we don't need to worry about that.

Thanks,
- Tom