On Saturday 25 October 2003 12:32 pm, Simon Burge wrote:
> On Fri, Oct 24, 2003 at 05:40:43PM +0000, Charles M. Hannum wrote:
> > On Friday 24 October 2003 05:31 pm, Matthias Drochner wrote:
> > > Hi -
> > > on a pmax/-current, compiled with gcc3, I'm observing
> > >
> > > # pmap
> > > 00000000     52K read/exec         /libexec/ld.elf_so
> > > 0000D000    252K                     [ anon ]
> > > 0004C000      8K read/write          [ anon ]
> > > 00400000    208K read/exec         /bin/csh
> > > [...]
> > >
> > > And indeed, a small (dynamically linked) test program can read
> > > from NULL, gets the contents of /libexec/ld.elf_so as expected.
> > >
> > > This shouldn't happen...
> >
> > MIPS is still defining ELF_INTERP_NON_RELOCATABLE, a vestige from before
> > I made ld.elf_so relocatable on that platform.  My guess is that a newer
> > version of binutils stopped linking it with the traditional VA offset
> > (0x5ffe0000), and so now it's mapping at 0.
> >
> > Either the ld scripts should be fixed to use the old offset, or
> > ELF_INTERP_NON_RELOCATABLE should be removed, or both.  It certainly
> > makes no sense as is.
>
> As Matthias mentioned, ld.elf_so is still linked at 0x5ffe0000 (for
> reasons I can't find - a long while ago I tried at VA offset 0 and
> everything still seemed to work fine).

It's due to changes in exec_elf32.c.  The non-relocatable case is just plain 
broken.