[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150310030342.GB23507@brightrain.aerifal.cx>
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.
