From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7168 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: aarch64 port Date: Mon, 9 Mar 2015 15:08:00 -0400 Message-ID: <20150309190800.GZ23507@brightrain.aerifal.cx> References: <20150309185058.GL16260@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1425928161 2947 80.91.229.3 (9 Mar 2015 19:09:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 9 Mar 2015 19:09:21 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7181-gllmg-musl=m.gmane.org@lists.openwall.com Mon Mar 09 20:09:14 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YV330-0004Fd-MT for gllmg-musl@m.gmane.org; Mon, 09 Mar 2015 20:09:02 +0100 Original-Received: (qmail 19801 invoked by uid 550); 9 Mar 2015 19:09:01 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 19624 invoked from network); 9 Mar 2015 19:08:12 -0000 Content-Disposition: inline In-Reply-To: <20150309185058.GL16260@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7168 Archived-At: 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