From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9836 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: vfork on ARM Date: Sun, 3 Apr 2016 20:14:43 -0400 Message-ID: <20160404001443.GH21636@brightrain.aerifal.cx> References: <56FDC407.2030405@gmail.com> <20160401015301.GY21636@brightrain.aerifal.cx> <5701A4B7.9020200@gmail.com> 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 1459728901 29988 80.91.229.3 (4 Apr 2016 00:15:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Apr 2016 00:15:01 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9849-gllmg-musl=m.gmane.org@lists.openwall.com Mon Apr 04 02:15:01 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 1amsAV-00016M-J9 for gllmg-musl@m.gmane.org; Mon, 04 Apr 2016 02:14:59 +0200 Original-Received: (qmail 27845 invoked by uid 550); 4 Apr 2016 00:14:57 -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 27824 invoked from network); 4 Apr 2016 00:14:56 -0000 Content-Disposition: inline In-Reply-To: <5701A4B7.9020200@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9836 Archived-At: On Mon, Apr 04, 2016 at 09:18:15AM +1000, Patrick Oppenlander wrote: > On 01/04/16 12:53, Rich Felker wrote: > >On Fri, Apr 01, 2016 at 11:42:47AM +1100, Patrick Oppenlander wrote: > >>I'm looking at what would be involved in using musl on a nommu arm system. > >> > >>As far as I know SYS_vfork is available on ARM, but musl is > >>currently falling back to fork. > >> > >>Are there any plans to support vfork on ARM and other architectures? > >It's trivial to add vfork, but the usefulness is limited without other > >changes: > > vfork should also be more efficient than fork which may be > motivation for supporting it as an optimisation on mmu targets. > > It's also theoretically possible to run a nommu kernel on an mmu > capable target. > > >1. To my knowledge, all nommu ARM systems are thumb[2]-only, so > >supporting them as targets requires adapting all the asm files to > >support building as thumb. This is a task in progress and, as long as > >we only care about thumb2 (available on armv7-m, i.e. Corext-M3 and > >up, I think) it's almost done. > > OK that's great! > > >2. For pre-v7, there's no way to do atomics without kernel help, and > >no established kernel API for this as far as I know. For v7-m this is > >probably not a problem. > > V6K has support for hardware atomics too. AFAIK even baseline v6 has ldrex/strex if you don't care about non-32-bit sizes (which musl doesn't). However it lacks a barrier instruction which is needed to make them useful. (Technically you can omit the barriee on UP but then you have dangerous binaries that break subtly when you move them to a SMP machine, and musl won't support making those, at least not upstream, as a matter of policy.) > v7-m supports 32-bit atomics but drops support for 64-bit (no LDREXD > or STREXD). Is a problem for musl? v7-m is fine with regard to atomics... > Do you know if v7-m has the hardware TLS registers? ...but it lacks the coprocessor register for TLS. However since the instruction to access it is representable in thumb2, the kernel could trap and emulate it. I think the people doing nommu ARM Linux stuff added a syscall for get_tls, but in theory that's just as costly as trap-and-emulate, so I'd rather get trap-and-emulate working so that the same binaries can run on v7-a without runtime selection of the TLS method. > >3. Running on nommu without shareable program text is not much fun; > >execve is really slow (memcpy of full program) and you need lots of > >memory. Some people at ST have implemented an FDPIC abi for ARM which > >solves this problem, but it's not upstream in the toolchain or kernel, > >and the relocation types it needs are not officially assigned. Getting > >it officially stabilized, supported, and forward-ported to modern tool > >versions is going to be a lot of work. Here are some slides on it: > > > >http://www.slideshare.net/linaroorg/sfo15406-arm-fdpic-toolset-kernel-libraries-for-cortexm-cortexr-mmuless-cores > > Thanks for the link. I wasn't aware of this. > > >Without FDPIC, it's possible to build a toolchain that produces > >static-PIE executables that will work on nommu (with my recently > >committed kernel patch for running non-FDPIC PIE ELF files on nommu, > >and some additional work still needed to hook it up to work on ARM) > >but these cannot use a shared mapping of the program. > > > >If you or anyone else is up for helping with these tasks that would be > >great. > > Right now I'm working on my own small kernel which will (hopefully) > implement enough of the linux syscall interface to be useful. It's > meant for small embedded microcontrollers where 4MiB of RAM is > considered luxurious. > > It's based on the now abandoned Prex operating system > (http://prex.sourceforge.net/) but is a major fork which goes back > to a traditional monolithic kernel model. I've replaced the C libary > with musl and userspace is currently toybox. > > I'm planning on releasing on github (BSD or no-license) once I can > boot the first targets (arm-mmu and arm-nommu) to a working > userspace and pass some unit tests. > > Maybe once I've learnt enough about how all this stuff works I'll be > able to contribute to other projects like linux/musl. If your intent to run a whole userspace environment on it, or just a single process? If the latter, plain (non-FDPIC) PIE ELF is not a bad solution at all. It precludes XIP from ROM, but at least you don't have repeated per-process overhead from many instances of same executable. Rich