Chung-Lin Tang <clt...@codesourcery.com> writes: > On 2012/8/30 02:44 AM, Richard Sandiford wrote: >> Chung-Lin Tang <clt...@codesourcery.com> writes: >>> On 2012/7/6 02:23 PM, Richard Sandiford wrote: >>>> Richard Sandiford <rdsandif...@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
