Date: Mon, 9 Mar 2015 23:03:42 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: aarch64 port On Tue, Mar 10, 2015 at 03:44:46AM +0100, Szabolcs Nagy wrote: > * 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 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 support. > > > __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 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 offset? > > > 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: > > > 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 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 places. > > > 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 alltypes.h.in would be very nice. > attached an incremental diff I don't see any issues in it aside from what's already being discussed. 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.