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

[will schmidt]

On Tue, 2022-05-10 at 11:02 -0700, Kevin Buettner via Gdb-patches
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.

Agree. :-)

I'm hoping Carl will still chime in here.   He committed a
change last year to add support for a couple of the syscalls ( commit
38c90362460000bac2efdbf06250821429777bb0 ).   That did not touch the
xml files at all, but would be good to have him confirm the changes in
the numbers is consistent with what he saw at the time.  

> 
> 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 agree with the sentiment.  I expect the syscall numbers to
rarely/never change.  A quick glance at the history of the syscall xmls
suggests to me that the xml files were added in 2009, and underwent a
regeneration in 2016, which looks like it may have been limited to just
added the group="foo" entries to the xml.     It could be this refresh
is getting GDB caught up with 13 or so years of kernel changes and
additions. 
> 
> Kevin
>