[ was : Re: [PATCH][gdb] Update syscalls/{amd64,i386}-linux.xml ]

On 5/16/22 18:07, Tom Tromey wrote:
>>>>>> "Tom" == Tom de Vries via Gdb-patches <gdb-patches@sourceware.org> writes:
> 
> Tom> On 5/9/22 12:39, Tom de Vries wrote:
>>> [ FWIW, it seems the linux kernel migrated to some syscall.tbl
>>> approach, and perhaps generating from there could be an option. ]
> 
> Tom> Well, I gave that a try, in a separate script update-linux-2.sh
> Tom> (haven't though of a good name yet).
> 

I've renamed to update-linux-from-src.sh.

> Tom> Any comments?
> 
> Maybe it should just replace update-linux.sh?
> 

ATM, not all archs use this .tbl format, notable exception being aarch64.

Besides, for the archs where the .tbl file is available, I like the 
ability to double check.

This new script is more powerful because it can generate for multiple 
architectures, but in doing so it does interpretation of the .tbl files 
in the kernel sources: which file to pick, which abi.

The update-linux.sh script uses the documented interface to syscalls: 
sys/syscalls.h  It's just that you need to run it on the particular 
platform (or, using cross compiler + sysroot), but I imagine maintainers 
of particular targets have this available.

> Tom> In particular, there are a few new "reserved<n>" and "unused<n>"
> Tom> entries that don't look problematic to me, but perhaps these should be
> Tom> filtered out.
> 
> I think it seems better to skip them.
> 

Done.

> Anyway if this is the direction Linux is going, like if this .tbl file
> is some authoritative source, 

Yes, the kernel sources use scripts to generate things like syscall 
headers from these .tbl files.

> then I think it makes the most sense for
> gdb to follow.

Ack, committed as attached.

Thanks,
- Tom