Linux: Add oddly-named arm syscalls to syscall-names.list

  (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)

These do not follow the regular __NR_* naming convention and
have so far been ignored by the syscall-names.list consistency
checks.  This commit adds these names to the file, preparing
for the availability of these names in the regular __NR_*
namespace.

2019-05-31  Florian Weimer  <fweimer@redhat.com>

	* sysdeps/unix/sysv/linux/syscall-names.list: Add oddly named
	system calls for the arm architecture: breakpoint, get_tls,
	set_tls, usr26, usr32.
  

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.

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.

But I think this patch is ok, anyway.

p.
  

* 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