Re: [PATCH] Linux: Add oddly-named arm syscalls to syscall-names.list

[Florian Weimer <fweimer at redhat dot com>]

* Phil Blundell:

> On Fri, May 31, 2019 at 02:13:02PM +0200, Florian Weimer wrote:
>> (Zack suggested I should post this separately.)
>> 
>> <asm/unistd.h> on arm defines the following macros:
>> 
>> #define __ARM_NR_breakpoint             (__ARM_NR_BASE+1)
>> #define __ARM_NR_cacheflush             (__ARM_NR_BASE+2)
>> #define __ARM_NR_usr26                  (__ARM_NR_BASE+3)
>> #define __ARM_NR_usr32                  (__ARM_NR_BASE+4)
>> #define __ARM_NR_set_tls                (__ARM_NR_BASE+5)
>> #define __ARM_NR_get_tls                (__ARM_NR_BASE+6)
>
> I think the reason these were originally given these weird names
> was exactly because these syscalls were not expected to have
> wrappers.  Generally that's because they either have strange
> semantics or they don't conform to the usual ABI.

cacheflush looks pretty standard to me.  set_tls is called
set_thread_area on several architectures, but it's true that all hell
breaks lose if you call this syscall from a program that uses glibc. 8-)

> Having a wrapper for usr26 and usr32 is almost certainly not
> useful, especially if we are contemplating removing support for
> ARMv4 (because these syscalls don't work on v4T or anything
> newer).  I'm not sure that having a wrapper for breakpoint
> is very useful either.  The other three probably do deserve
> wrappers and arguably ought to have been given regular __NR_ 
> names in the first place.

Just to clarify, the patch is essentially a NOP because we never define
a SYS_cacheflush macro unless there is also a __NR_cacheflush macro
provided by <asm/unistd.h>, and today, there is not.  This list is only
used for generating the <bits/syscall.h> header (which provides these
conditional SYS_ macros), and for internal consistency checks.

It's the latter that I'm concerned with.  I plan to add

#define __NR_cacheflush __ARM_NR_cacheflush
#define __NR_set_tls __ARM_NR_set_tls

to the *internal* glibc syscall header, and treat these two system calls
as regular calls, thus avoiding the need for INTERNAL_SYSCALL_ARM and
various new special cases in the upcoming system call table machinery.
(These names will not be visibile externally.)

Thanks,
Florian