From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10023 Path: news.gmane.org!not-for-mail From: Bobby Bingham Newsgroups: gmane.linux.lib.musl.general Subject: Re: porting musl to RISCV-64 Date: Wed, 11 May 2016 13:48:28 -0500 Message-ID: <20160511184828.GA13552@gordon> References: <20160511112518.GB22574@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1462992528 23448 80.91.229.3 (11 May 2016 18:48:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 May 2016 18:48:48 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-10036-gllmg-musl=m.gmane.org@lists.openwall.com Wed May 11 20:48:44 2016 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 1b0ZBa-0002RI-N2 for gllmg-musl@m.gmane.org; Wed, 11 May 2016 20:48:42 +0200 Original-Received: (qmail 15704 invoked by uid 550); 11 May 2016 18:48:40 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 15683 invoked from network); 11 May 2016 18:48:40 -0000 Content-Disposition: inline In-Reply-To: X-Operating-System: Linux gordon 3.18.1-gentoo User-Agent: Mutt/1.6.0 (2016-04-01) Xref: news.gmane.org gmane.linux.lib.musl.general:10023 Archived-At: On Wed, May 11, 2016 at 09:32:16AM -0700, Gry Gunvor wrote: > On Wed, May 11, 2016 at 4:25 AM, Szabolcs Nagy wrote: > > > newlib is for baremetal development, you don't > > need to use threading with it > > It's attempt at reentrancy support is causing me problems. > > > musl now has 32bit mips, mips64 and mipsn32 support as well. > > these are different abis so they have to be separate ports, > > same is true for the riscv targets. > > Your documentation does not seem to mention the MIPS64 port, but now > that I look in arch, I see the directory for it. This is a pretty new port. The documentation just hasn't been updated yet. > > > there is a google summer of code project to add riscv support > > http://www.openwall.com/lists/musl/2016/04/27/3 > > i think it is supposed to provide a working port within 1-2 > > months (?) so if you can wait you don't need to do much work. > > Suppose I can't wait and I attempt this myself. Right now I'm just > trying to get a generic libc working. I do not want to handle > multi-threading or signals. What can I omit? Are the > non-portabilities isolated in arch/ ? That is, is there much more to > it than cloning the arch/mips64 directory and hacking on it? There are some bits of architecture-specific assembly scattered elsewhere (crti/crtn, setjmp/longjmp, syscall, syscall_cp). The __clone function which is used to create new threads is also used internally to implement a couple other functions that aren't strictly threading-related (eg, posix_spawn and a fallback version of faccessat), so if you omit it those functions may also not be usable. > > atomic_arch.h: I think I can make all of these functions empty as I am > not going to be using multi-threading, right? These functions don't really need to be atomic for a single thread to work, but they do still need to perform the correct operations. If you're ignoring the atomicity required for multi-threaded code, these are all trivial to implement in C. > > crt_arch.h: program startup; what is this doing in a libc > implementation? doesn't the compiler handle this? This has the entry point that is invoked by the kernel, and handles the little bit of setup necessary for handing off control to C code. > > ksigaction.h: sorry, I'm not a hardware person; I suppose different > hardware has a different default layout for a signal object? so this > is not a thing determined by kernel software? I don't care to handle > signals right now anyway. This needs to match the kernel. Not all musl ports have this file. Some use the generic version in src/internal/ksigaction.h > > pthread_arch.h: again, I think I can make all of these functions empty > as I am not going to be using multi-threading. This is code for working with the thread pointer and thread-local storage. Even if you only have a single thread, this is still necessary. For example, errno is thread-local and is accessed through the thread pointer (see the definition of __errno_location). > > reloc.h: I can't figure out what this is. It's definitions for the dynamic linker. > > syscall_arch.h: I've already written this for RISCV-64 (and so have > the RISCV people). > > bits: to what extent is this MIPS64-specific? since there is *no* > inline assembly, how come arch/generic/ doesn't do here? A small amount of it depends on the hardware (fenv) or on the ABI (alltypes). Most of it though just needs to match the kernel, and the Linux kernel definitions vary by architecture. -- Bobby