This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [aarch64] question about user.h, ucontext.h, procfs.h
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: GNU C Library <libc-alpha at sourceware dot org>
- Cc: Marcus Shawcroft <Marcus dot Shawcroft at arm dot com>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>
- Date: Thu, 23 Apr 2015 14:46:33 +0100
- Subject: Re: [aarch64] question about user.h, ucontext.h, procfs.h
- Authentication-results: sourceware.org; auth=none
- References: <54FDBC60 dot 6020902 at arm dot com>
On 09/03/15 15:29, Szabolcs Nagy wrote:
> some questions about aarch64 headers:
>
> (1) 32bit greg_t in ucontext.h
>
> i noticed that sysdeps/unix/sysv/linux/aarch64/sys/ucontext.h
> defines greg_t as
>
> typedef int greg_t;
>
this should be fixed
> which seems wrong (i'd expect unsigned long and that's how
> elf_greg_t is defined).
>
> other archs use greg_t in the definition of mcontext_t, but
> aarch64 gets that from the kernel headers (asm/sigcontext.h)
>
> is greg_t used outside of libc?
> can i fix it to have more reasonable definition?
> is it ok to depend on linux headers in ucontext.h?
>
> (2) 16bit uid, gid in procfs.h
>
> aarch64 elf_prpsinfo struct has
>
> unsigned short int pr_uid;
> unsigned short int pr_gid;
>
likewise
> members, which seems wrong (i'd expect unsigned int like in
> the kernel linux/elfcore.h)
>
> the procfs.h header seems to be something that should be
> only used by debuggers which probably rely on kernel headers
> or define their own instead of using libc headers.
> is this correct?
> can i fix this?
> should this header be removed completely?
>
> (3) __uint128_t in user.h
>
> aarch64 user_fpsimd_struct has
>
> __uint128_t vregs[32];
>
> member to represent the 128bit floating point registers
>
> is it ok to expose __uint128_t in public headers?
>
(i'd prefer 'long double' so compilers without __uint128
can use signal.h)
these are abi breaking changes, what is the policy for that,
can i fix it?