This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 2/2] MIPS16: MIPS16 support proper
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