On 5/9/22 16:48, Simon Marchi wrote:
> On 2022-05-09 06:39, Tom de Vries wrote:
>> [ was: Re: [PATCH][gdb/tdep] Support catch syscall pipe2 for i386 ]
>>
>> On 5/5/22 15:20, Simon Marchi wrote:
>>> I suppose we are missing more syscalls than that, given that new
>>> syscalls are added regularly, e.g. rseq:
>>>
>>>     https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d7822b1e24f2
>>>
>>> As long as rseq is not listed in this file, it means a user wouldn't be
>>> able to use "catch syscall rseq", I suppose?  We would need a procedure
>>> to add new syscalls periodically.
>>>
>>
>> I've wrote a script gdb/syscalls/update-linux.sh that can be used to do the update automatically.  The idea being that target maintainers can run the script on their platform and do the update.
>>
>> AFAICT, the previous approach was to generate directly from kernel sources.  The benefit there is that you don't need access to a specific platform to do the update (but you'd still need access to test I suppose).
>>
>> [ FWIW, it seems the linux kernel migrated to some syscall.tbl approach, and perhaps generating from there could be an option. ]
>>
>> Anyway, this script at least adds one option to do the update.
>>
>> WDYT?
> 
> One flake8 warning:
> 
> gen-header.py:9:1: F401 're' imported but unused
> 
> I would also suggest running shellcheck on the .sh script and
> fix the issues, it gives generally good suggestions.
> 
> LGTM otherwise.
> 

Thanks for pointing those out, fixed.

> So, was this:
> 
> -  <syscall name="madvise1" number="220"/>
> -  <syscall name="getdents64" number="221" groups="descriptor"/>
> -  <syscall name="fcntl64" number="222" groups="descriptor"/>
> +  <syscall name="getdents64" number="220" groups="descriptor"/>
> +  <syscall name="fcntl64" number="221" groups="descriptor"/>
> 
> an existing mistake in our syscall list?
> 

That's my understanding, yes.

If you look at older linux sources, say v3.0, you find the file 
mentioned as generation source ( arch/x86/include/asm/unistd_32.h ) , 
and it contains:
...
#define __NR_madvise            219
#define __NR_madvise1           219     /* delete when C lib stub is 
removed */
#define __NR_getdents64         220
#define __NR_fcntl64            221
/* 223 is unused */
#define __NR_gettid             224
...

It's possible that the generation scripts that were used didn't deal 
correctly with the repetition of the syscall number.

Committed as attached.

Thanks,
- Tom