[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
