Re: [PATCH 2/2] MIPS16: MIPS16 support proper

["Maciej W. Rozycki" <macro@codesourcery.com>]

On Mon, 28 Jan 2013, Richard Henderson wrote:

> > OK, I see where this is happening now.  crti (from glibc) is mips16 and
> > crtbegin (from gcc) is mips32.  crtbegin is mips32 because it uses
> > CRT_CALL_STATIC_FUNCTION and that has '.nomips16' in it.  I am not sure
> > how to rewrite CRT_CALL_STATIC_FUNCTION in mips16 to avoid this and it
> > looks like the codesourcery version of GCC is handling this by making
> > all .init/.fini code mips32 instead of mips16.  So, should I try to make
> > crti use a mips32 .init or make crtbegin use a mips16 .init?  I am not
> > sure which is better.
> 
> FWIW, I think you're better off considering the .init section to be
> mips32 code always, as a part of the ABI.  That way stuff that worked
> before continues to work, and no one has to worry about how the
> installed toolchain itself is configured.

 That may work as a temporary measure for MIPS16 code only, as any 
processor that supports MIPS16 execution must also support standard MIPS 
execution.

 However we have the very same problem with microMIPS code -- that glibc 
supports out of the box thanks to the high level of source compatibility 
the ISA provides and GCC support for which is currently under review.  
There we cannot agree upon using standard MIPS code in .init/.fini because 
we have conflicting objectives to choose from:

1. We want to support mixing standard MIPS and microMIPS code, so we 
   cannot assume all binary modules in a static link will use the same 
   encoding.

2. We want to support processors that only support either instruction 
   encoding, so the encoding of .init/.fini code has to match the encoding 
   of the remaining parts of the module concerned.

And regardless of the scenario chosen we want to keep the same binary 
modules built for either ISA without the need to rebuild any parts of 
them.

> And of course as you note elsewhere, this is an excellent time to
> have new toolchains stop using .init, as DT_INIT_ARRAY has none of
> these problems.

 Given the above I think we need it sooner rather than later.  Who's got 
the power to make it happen?

  Maciej