Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150309190800.GZ23507@brightrain.aerifal.cx>
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.