This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [aarch64] question about user.h, ucontext.h, procfs.h


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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]