[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150310024446.GN16260@port70.net>
Date: Tue, 10 Mar 2015 03:44:46 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: aarch64 port
* 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
> > __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
View attachment "incremental.diff" of type "text/x-diff" (9366 bytes)
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.
