Problems with mips2 compiled libc and linux 2.4.3

Problems with mips2 compiled libc and linux 2.4.3

[Brian Murphy]

It seems that this check(in asm-mips/elf.h):

#define elf_check_arch(hdr)
\
({
\
        int __res = 1;
\
        struct elfhdr *__h = (hdr);
\

\
        if ((__h->e_machine != EM_MIPS) &&
\
            (__h->e_machine != EM_MIPS_RS4_BE))
\
                __res = 0;
\
        if (__h->e_flags & EF_MIPS_ARCH)
\
                __res = 0;
\

\
        __res;
\
})

which is called in fs/binfmt_elf.c causes the loading of init to fail if

it is linked with a glibc compiled with -mips2. It is the second if test

which fails if any of the high 4 bits in the flags are set. According to
the
specs these are set for the various mipsx (x != 1) flavors - this seems
to mean
that we do no allow anything higher than mips1 run on linux - can this
be
true? If so, why?

/Brian

Re: Problems with mips2 compiled libc and linux 2.4.3

[Ralf Baechle]

On Mon, Jun 18, 2001 at 08:11:36PM +0200, Brian Murphy wrote:

>         if (__h->e_flags & EF_MIPS_ARCH)
> \
>                 __res = 0;

> which is called in fs/binfmt_elf.c causes the loading of init to fail if
> it is linked with a glibc compiled with -mips2. It is the second if test
> which fails if any of the high 4 bits in the flags are set. According to
> the specs these are set for the various mipsx (x != 1) flavors - this seems
> to mean that we do no allow anything higher than mips1 run on linux -
> can this be
> true? If so, why?

Older binutils didn't use to set these flags but SGI's ld did so this was
a heuristc to reject IRIX binaries which are handled by irixelf.c.  The
fix is simple, just remove above test.

Time to come up with some other plan to detec IRIX binaries ...

  Ralf

Re: Problems with mips2 compiled libc and linux 2.4.3

[H . J . Lu]

On Mon, Jun 18, 2001 at 08:11:36PM +0200, Brian Murphy wrote:
> 
> it is linked with a glibc compiled with -mips2. It is the second if test

I patched my kernel to get around it.

> 
> which fails if any of the high 4 bits in the flags are set. According to
> the
> specs these are set for the various mipsx (x != 1) flavors - this seems

> to mean
> that we do no allow anything higher than mips1 run on linux - can this
> be
> true? If so, why?

There is no very good reason. I think we should add a MIPS ISA level
field in the mips cpuinfo so that we can check what ISA the hardware
support at the run-time.


H.J.

Re: Problems with mips2 compiled libc and linux 2.4.3

[Brian Murphy]

Ralf Baechle wrote:

> On Mon, Jun 18, 2001 at 08:11:36PM +0200, Brian Murphy wrote:
>
> >         if (__h->e_flags & EF_MIPS_ARCH)
> > \
> >                 __res = 0;
>
>

Will this be removed from the cvs version then?

With all the talk of ll/sc and mips 1 and 2  in the last few months
how has anyone tested/run with a mips2 libc if this test existed in
their kernel?

/Brian

Re: Problems with mips2 compiled libc and linux 2.4.3

[Ralf Baechle]

On Mon, Jun 18, 2001 at 11:22:53AM -0700, H . J . Lu wrote:

> > which fails if any of the high 4 bits in the flags are set. According to
> > the
> > specs these are set for the various mipsx (x != 1) flavors - this seems
> 
> > to mean
> > that we do no allow anything higher than mips1 run on linux - can this
> > be
> > true? If so, why?
> 
> There is no very good reason. I think we should add a MIPS ISA level
> field in the mips cpuinfo so that we can check what ISA the hardware
> support at the run-time.

Yes and no.  It would be nice but the available flags are not an suitable
representation of processor capabilities.

  Ralf