Date: Mon, 9 Mar 2015 15:08:00 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: aarch64 port On Mon, Mar 09, 2015 at 07:50:58PM +0100, Szabolcs Nagy wrote: > attached patch adds aarch64 support Thanks!! > tested on foundation model + linaro rootfs, there are some issues still: > > dynlink > 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 symbol version to look for. This is both a bloat-saving measure for archs that don't have a useful vdso, and a safety measure against the possibility that the kernel adds an ABI-incompatible version of the vdso function for some arch (which would cause old binaries to start crashing on new kernels with the vdso). > __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. > __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. > 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. > socket.h > needs __BYTE_ORDER workarounds, not tested on bigendian > i think i need to include endian.h somewhere i think this should be ok > but not tested on bigendian endian.h is namespace-safe with standards-conforming feature profiles. Maybe we should eventually factor it to avoid pulling in the non-namespace-safe stuff in _DEFAULT_SOURCE but that's a separate issue that doesn't matter for the port. > ioctl.h > may needs some further checks > i removed TCGETS2,etc which used struct termios2 > atomic.h > a_crash probably should be a single instruction > a_spin is probably fine but pthread_spin* could be improved I'll take a look. > 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. > 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. > 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. > reg.h > sys/reg.h seems to be x86 only (and m68k) in glibc, so probably it should > be left empty.. OK. > 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. > 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. Rich
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.