Re: [PATCH v2 3/7] perf syscalltbl: Remove struct syscalltbl

From: Arnd Bergmann
Date: Tue Feb 11 2025 - 02:49:48 EST


On Mon, Feb 10, 2025, at 17:51, Ian Rogers wrote:
> The syscalltbl held entries of system call name and number pairs,
> generated from a native syscalltbl at start up. As there are gaps in
> the system call number there is a notion of index into the
> table. Going forward we want the system call table to be identifiable
> by a machine type, for example, i386 vs x86-64. Change the interface
> to the syscalltbl so (1) a (currently unused machine type of EM_HOST)
> is passed (2) the index to syscall number and system call name mapping
> is computed at build time.
>
> Two tables are used for this, an array of system call number to name,
> an array of system call numbers sorted by the system call name. The
> sorted array doesn't store strings in part to save memory and
> relocations. The index notion is carried forward and is an index into
> the sorted array of system call numbers, the data structures are
> opaque (held only in syscalltbl.c), and so the number of indices for a
> machine type is exposed as a new API.
>
> The arrays are computed in the syscalltbl.sh script and so no start-up
> time computation and storage is necessary.
>
> Signed-off-by: Ian Rogers <irogers@xxxxxxxxxx>
> Reviewed-by: Howard Chu <howardchu95@xxxxxxxxx>

Your changes look fine to me, but I noticed one part that may
be wrong before and after your patch:

>
> -const int syscalltbl_native_max_id = SYSCALLTBL_MAX_ID;
> -static const char *const *syscalltbl_native = syscalltbl;
> +const char *syscalltbl__name(int e_machine __maybe_unused, int id)
> +{
> + if (id >= 0 && id <= (int)ARRAY_SIZE(syscall_num_to_name))
> + return syscall_num_to_name[id];
> + return NULL;
> +}

The syscall numbers on mips (and previously on ia64) are offset by
a large number depending on the ABI (o32/n32/n64). I assume what
we want here is to have the small numbers without the offset in
syscall_num_to_name[], but that requires adding the offset during
the lookup. Can you check if this is handled correctly?

Arnd