This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] MIPS16 TLS support for GCC
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Chung-Lin Tang <cltang at codesourcery dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, "Maciej W. Rozycki" <macro at codesourcery dot com>
- Date: Thu, 30 Aug 2012 21:19:54 +0100
- Subject: Re: [PATCH] MIPS16 TLS support for GCC
- References: <4F0709B3.8060202@codesourcery.com> <87r4zaxwx6.fsf@firetop.home> <4F2BB0C1.4010605@codesourcery.com> <g4zkd0gcms.fsf@richards-thinkpad.stglab.manchester.uk.ibm.com> <4FF53934.5000408@codesourcery.com> <87hatm9gxt.fsf@talisman.home> <878vex9zlt.fsf@talisman.home> <503DE312.8000901@codesourcery.com> <87vcg1zges.fsf@talisman.home> <503EFCE0.3040304@codesourcery.com>
Chung-Lin Tang <cltang@codesourcery.com> writes:
> 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.
Thanks.
> 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.
TBH, I'm not sure off-hand whether MULTILIB_EXCLUSIONS takes account
of --with-arch-style defaults. (As in: it might well do.)
Even if it does, though, I still think --with-multilib-list would be
the right way of adding a mips16 multilib. It's just that having an
out-of-the-box way of getting a mips16 multilib seems less important
now than it did originally (because the original patch added code that
wouldn't be used without such a multilib, whereas the current patch just
adds obviously-correct nomips16 attributes).
"Not important" doesn't mean "not useful", of course. Having
--with-multilib-list would still very nice to have if anyone
feels suitably inclined.
Richard