Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 9 Mar 2015 23:03:42 -0400
From: Rich Felker <>
Subject: Re: aarch64 port

On Tue, Mar 10, 2015 at 03:44:46AM +0100, Szabolcs Nagy wrote:
> * Rich Felker <> [2015-03-09 15:08:00 -0400]:
> > On Mon, Mar 09, 2015 at 07:50:58PM +0100, Szabolcs Nagy wrote:
> > > 	should work, relocs lisghtly tested, but vdso does not work
> > > 	yet (at least i see clock_gettime syscalls in strace)
> > 
> > vdso is unrelated to the dynamic linker. You have to add macros in
> > syscall_arch.h to inform clock_gettime that vdso is useful, and what
> vdso works now

Great! Can you confirm whether enabling it on 32-bit ARM would be okay
too? I've been unable to get a setup with the right hardware/kernel
combination for testing and I don't want to commit completely untested

> > > __syscall_cp_asm
> > > 	i used "cbnz w0,__cancel", that is "compare and branch on nonzero"
> > > 	but it has a +-1M limit on the jump is that ok?
> > 
> > For dynamic linking, yes, as long as is under 1M. But for
> > static linking, probably not. In principle __cancel and
> > __syscall_cp_asm could be far away in a huge static binary.
> > 
> hm pc relative branches have limited range, maybe i should use
> barnch to register with some address calculation? what's the best
> way to do that?
> for now i used a branch with +-128M range

On most 64-bit archs a sort of "small model" is in effect where any
given DSO's code/data is assumed to be addressible with signed 32-bit
PC-relative addresses. So I think ±128M is more than sufficient.

> > > __tlsdesc_dynamic
> > > 	needs to access dtv for which the asm needs sizeof(struct pthread)
> > > 	so we may want to add the dtv at the end of pthread struct too
> > 
> > Yes, I'd like to add a copy (or just move it) at the end contingent
> > upon TLS_ABOVE_TP.
> i just added a todo about this

Would you like me to make this change prior to committing aarch64 so
you could use the assumption that dtv is accessible at a fixed small

> > > syscall.h
> > > 	is aarch64 only syscalls ok here or do we want a generic
> > > 	32bit+64bit syscall header like kernel has now for new archs?
> > 
> > I don't follow.
> > 
> sorry  i was thinking that now that the kernel has generic syscalls
> we could use one syscall.h (it is fairly big and could be shared
> between every new arch) only a few syscalls need to be different
> on 32bit vs 64bit archs
> for now i made syscall.h 64bit only (the 32bit version is in or1k/bits)

Yes, it would be really nice to move to an arch/bits form with base
files and only limited arch-specific overrides, and having all the
bits headers be generated (or maybe even inlined into their respective
top-level header files to eliminate bits?).

> > > signal.h, user.h
> > > 	exposes ucontext stuff which uses __attribute__((aligned(16))) (can be
> > > 	fixed with manual padding i guess, i just copied the kernel sigcontext)
> > > 	and fpregset_t uses __uint128_t (for ld128 float registers).
> > > 	if we decide that __uint128 is ok for platforms with 128 bit
> > > 	long double then i'll change internal/libm.h etc to avoid the
> > > 	ugly endian dependent bithacks
> > 
> > I'll look. Perhaps just including a long double element or similar can
> > get the desired effect portably.
> > 
> see mcontext_t in bits/signal.h and user_fpsimd_struct in bits/user.h
> i added todo comment for now

OK. Just checked it and it seems like __reserved could just have type
long double (or a union containing long double) in both the full and
namespace-safe versions.

> > > long double:
> > > 	printf/scanf/.. should work but some math functions
> > > 	are missing/broken now, there is an exp2l patch that
> > > 	is needed before this one to make things compile
> > 
> > Broken (bad accuracy) is OK for now, but we should probably fix any
> > missing symbols.
> > 
> i can add dummy long double functions that map to the double version
> missing ones (not counting complex):

Are the complex ones ld-format-specific anyway? I figured they would
just be written in terms of real ld functions.

>  acoshl
>  asinhl
>  atanhl
>  coshl
>  erfcl
>  erfl
>  expl
>  expm1l
>  lgammal
>  log10l
>  log1pl
>  log2l
>  sinhl
>  tanhl
>  tgammal

Thanks for the list.

> > > shm.h
> > > 	shminfo should be under _GNU_SOURCE according to the manual:
> > >
> > > 	however shm* is reserved namespace for sys/shm.h
> > > 	(i used _GNU_SOURCE in aarch64, others lack it)
> > 
> > I prefer to keep FTM checks out of the bits headers as much as possible.
> ok removed it

OK. BTW the rationale here is that errors or need for changes in FTM
behavior are easily overlooked if they're tucked away in arch-specific

> > > termios.h
> > > 	i havent tested this much
> > > 	but kernel NCCS 32 vs 19 we use in various archs seems inconsistent
> > 
> > glibc generally does its own thing rather than matching the kernel. We
> > do a sort of ugly mix I think... I'd need to check again to be sure
> > though.
> i think ioctl and termios should be checked against the kernel
> if we are up to date (not just for aarch64) but it's painful..

Yes and yes (that it should be checked, and that checking is painful).

> i changed the pthread types to match x86_64 as that seems to me
> the most reasonable approach

Yes that's the way I'm leaning -- 40-byte rather than 32-byte. Having
the pthread types in the shared part of would be very

> attached an incremental diff

I don't see any issues in it aside from what's already being discussed.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.