Re: [PATCH] MIPS16 TLS support for GCC

[Chung-Lin Tang <cltang at codesourcery dot com>]

On 2012/8/30 02:44 AM, Richard Sandiford wrote:
> Chung-Lin Tang <cltang@codesourcery.com> writes:
>> On 2012/7/6 02:23 PM, Richard Sandiford wrote:
>>> Richard Sandiford <rdsandiford@googlemail.com> writes:
>>>>> (3) Also related to libraries, I edited CRT_CALL_STATIC_FUNCTION to emit
>>>>> a 32-bit code sequence under both MIPS/MIPS16 mode (under O32).
>>>>>
>>>>> As you can see in the original Feb. patch, I had changes to emit a
>>>>> MIPS16 version of these static calls, but with the changes in (2) above,
>>>>> they will not work with the usual situation of a 32-bit MIPS built /lib
>>>>> (.init/.fini will have 32/16-bit code improperly concatenated).
>>>>>
>>>>> The CodeSourcery builds use an independent mips16 sysroot for this, so a
>>>>> MIPS16 CRT_CALL_STATIC_FUNCTION works there. For the usual case, I think
>>>>> making it 32-bit is the compatible choice.
>>>>
>>>> Yeah, I agree that sounds like the right call.  Please do the same
>>>> for the n32/n64 version (i.e. explicitly make it nomips16 rather
>>>> than add the #error).
>>>
>>> BTW, doing this has removed my main concern about having dead code.
>>> The original patch had a separate MIPS16 implementation that (as things
>>> stood) could never be used by stock sources.  That would make it difficult
>>> to maintain.
>>>
>>> Now that the MIPS16 library support is purely adding nomips16 attributes
>>> to code that is obviously nomips16, those parts are OK on their own, thanks.
>>> (I.e. the mips.h change, the libgcc change, and the libgomp change.)
>>> Feel free to drop the multilib thing if you don't want to implement
>>> --with-multilib-list.
>>
>> Hi Richard, just FYI, I just committed the said approved parts.
>> gcc/config/mips/t-linux64 had one additional change, adding
>> ../lib/mips16 to the corresponding MULTILIB_OSDIRNAMES, or else we end
>> with a weird option-named directory for the mips16 libraries.
> 
> Sorry, but the t-linux64 stuff wasn't approved.  It was just the mips.h
> change, the libgcc change and the libgomp change.
> 
> Please revert the patch to t-linux64.  My original objection to adding
> mips16 unconditionally still stands: it isn't correct for people who
> configure for processors that don't have the MIPS16 ASE (such as Octeon).

I have reverted that part.
Maybe a list of proper march=XXX/mips16 added to MULTILIB_EXCLUSIONS
will do what you're mentioning, though I haven't tried testing that for now.

Thanks,
Chung-Lin