From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4753 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Any plans on MMU-less support? Date: Sun, 30 Mar 2014 19:17:47 -0400 Message-ID: <20140330231747.GB26358@brightrain.aerifal.cx> References: <5337BE64.2010504@gmail.com> <20140330150139.GJ27448@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 1396221489 8453 80.91.229.3 (30 Mar 2014 23:18:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Mar 2014 23:18:09 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4757-gllmg-musl=m.gmane.org@lists.openwall.com Mon Mar 31 01:18:05 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WUOzM-00027u-AM for gllmg-musl@plane.gmane.org; Mon, 31 Mar 2014 01:18:04 +0200 Original-Received: (qmail 11955 invoked by uid 550); 30 Mar 2014 23:18: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 11942 invoked from network); 30 Mar 2014 23:18:00 -0000 Content-Disposition: inline In-Reply-To: <20140330150139.GJ27448@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4753 Archived-At: On Sun, Mar 30, 2014 at 05:01:39PM +0200, Szabolcs Nagy wrote: > * Smirnov Vladimir [2014-03-30 15:49:08 +0900]: > > I wonder if MUSL have such roadmap or there is any hackish way to > > add that support (may be some unoffitial patches). > > My problem that i've stucked with old gcc toolchain and uClibc > > supporting one widely used ARMv4 MMUless chip. > > looking at uClibc the main differences in a no-mmu system: > > fork is not available so related functions have to be changed/disabled > (vfork, daemon, wordexp, forkpty, pthread_atfork) vfork does not use fork except as a default implementation when no arch-specific file exists. The rest are probably mostly uninteresting to nommu; in any case, they're not something libc can fix, but things apps must avoid using to work on nommu. > brk is not available so malloc needs to change Thankfully support for the case where brk fails is already on the agenda due to the kernel bug that affects PIE. > mmap may need MAP_UNINITIALIZED flag for performance This is unrelated to libc and gives wrong semantics. If apps want they can do it, but it's really a bad idea. > (and MAP_FIXED flag will fail) Just for MAP_SHARED. > memory management related things may need to be changed/disabled > (mprotect?,mlock,msync,..) Shouldn't affect libc. > for dynamic linking ldso and libc startup code may need some change > (some targets (not arm) need fdpic or dsbt elf support) > (others can use a shared flat binary format) This is definitely a topic that needs more research. I doubt dynamic linking could be made to work easily. > pthread may need smaller default stack and more careful stack usage This only matters if the machine has a tiny amount of memory; it's orthogonal to nommu. > arm startup code needs a change according to > http://git.uclibc.org/uClibc/tree/libc/sysdeps/linux/arm/crt1.S#n179 This is rather hideous. Rich