Any plans on MMU-less support?

Any plans on MMU-less support?

[Smirnov Vladimir]

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.

Re: Any plans on MMU-less support?

[Szabolcs Nagy]

* Smirnov Vladimir <mapron1@gmail.com> [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)

brk is not available so malloc needs to change

mmap may need MAP_UNINITIALIZED flag for performance
(and MAP_FIXED flag will fail)

memory management related things may need to be changed/disabled
(mprotect?,mlock,msync,..)

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)

pthread may need smaller default stack and more careful stack usage

arm startup code needs a change according to
http://git.uclibc.org/uClibc/tree/libc/sysdeps/linux/arm/crt1.S#n179

and you may need to fix various toolchain issues..

Re: Any plans on MMU-less support?

[Rich Felker]

On Sun, Mar 30, 2014 at 05:01:39PM +0200, Szabolcs Nagy wrote:
> * Smirnov Vladimir <mapron1@gmail.com> [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

Re: Any plans on MMU-less support?

[Владимир Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1425 bytes --]

I already using uClibc so i know that i hardly ever have fork or dynamic
linkage. It's all suitable for me.
So whats up with mmap and startup code?
I wonder on minimal working set of that all :-)


2014-03-31 0:01 GMT+09:00 Szabolcs Nagy <nsz@port70.net>:

> * Smirnov Vladimir <mapron1@gmail.com> [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)
>
> brk is not available so malloc needs to change
>
> mmap may need MAP_UNINITIALIZED flag for performance
> (and MAP_FIXED flag will fail)
>
> memory management related things may need to be changed/disabled
> (mprotect?,mlock,msync,..)
>
> 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)
>
> pthread may need smaller default stack and more careful stack usage
>
> arm startup code needs a change according to
> http://git.uclibc.org/uClibc/tree/libc/sysdeps/linux/arm/crt1.S#n179
>
> and you may need to fix various toolchain issues..
>

[-- Attachment #2: Type: text/html, Size: 2044 bytes --]

Re: Any plans on MMU-less support?

[Szabolcs Nagy]

* Rich Felker <dalias@aerifal.cx> [2014-03-30 19:17:47 -0400]:
> On Sun, Mar 30, 2014 at 05:01:39PM +0200, Szabolcs Nagy wrote:
> > 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.

i meant in malloc (and similar usage inside libc)

(i dont think inter-process information leak needs to be considered on nommu)