* Rich Felker <dalias@libc.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