Date: Tue, 10 Mar 2015 03:44:46 +0100 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Subject: Re: aarch64 port * Rich Felker <dalias@...c.org> [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 > > __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 libc.so 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 > > __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 > > 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) > > 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 > > 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): acoshl asinhl atanhl coshl erfcl erfl expl expm1l lgammal log10l log1pl log2l sinhl tanhl tgammal > > generic issues (affect other archs too): > > > > sigsetjmp.h > > sigprocmask vs pthread_sigmask: the only difference is errno > > i dont see errno requirement for sigsetjmp so pthread_sigmask should be ok? > > I think so. > i left this alone now for consistency with other archs > > reg.h > > sys/reg.h seems to be x86 only (and m68k) in glibc, so probably it should > > be left empty.. > > OK. > likewise (will need to be fixed together with other archs) > > shm.h > > shminfo should be under _GNU_SOURCE according to the manual: > > http://man7.org/linux/man-pages/man2/shmctl.2.html > > 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 > > 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.. i changed the pthread types to match x86_64 as that seems to me the most reasonable approach attached an incremental diff View attachment "incremental.diff" of type "text/x-diff" (9366 bytes)
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.