This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Stepping down
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: Roland McGrath <roland at hack dot frob dot com>, Kaz Kojima <kkojima at rr dot iij4u dot or dot jp>, <libc-alpha at sourceware dot org>
- Date: Thu, 11 Jun 2015 15:54:30 +0000
- Subject: Re: Stepping down
- Authentication-results: sourceware.org; auth=none
- References: <20150609 dot 075619 dot 135637161 dot kkojima at rr dot iij4u dot or dot jp> <20150611001026 dot 040F02C3C1B at topped-with-meat dot com> <20150611025850 dot GV17573 at brightrain dot aerifal dot cx> <alpine dot DEB dot 2 dot 10 dot 1506111439470 dot 21804 at digraph dot polyomino dot org dot uk> <20150611152542 dot GX17573 at brightrain dot aerifal dot cx>
On Thu, 11 Jun 2015, Rich Felker wrote:
> > There is no no-MMU support in glibc (though I see no reason in principle
> > it shouldn't be possible to support it cleanly enough to get accepted if
> > anyone wishes to contribute patches - ELF no-MMU binaries not FLT, that
> > is).
>
> I have a preliminary patch (possibly some small cleanup needed) posted
> on the musl list (http://www.openwall.com/lists/musl/2015/06/10/1)
> that makes it so the fdpic elf loader in the kernel can load normal,
> non-fdpic ELF files too. In principle this makes it possible to use
> glibc with minimal/no modification, but without fdpic I think the
> per-process memory usage (and time spent memcpy'ing it in mmap) from
> glibc would be prohibitive for most applications.
And it's quite likely there are things relying on fork that could usefully
be supported on no-MMU, but would need different implementations there
(possibly in sysdeps/nommu).
> Yes, I was wondering about where it disappeared to. I found where the
> binutils-side patches were upstreamed, but couldn't find even the
> proposed patches for GCC. This really should be revived and
> upstreamed.
Googling for 'site:gcc.gnu.org gcc-patches sh fdpic' finds them easily
enough. It looks like the SH-specific part
<https://gcc.gnu.org/ml/gcc-patches/2010-08/msg01464.html> was accepted,
while it was the preparatory
<https://gcc.gnu.org/ml/gcc-patches/2010-08/msg01462.html> that was
problematic.
--
Joseph S. Myers
joseph@codesourcery.com