Re: [PATCH] MIPS16 TLS support for GCC

[Richard Sandiford <rdsandiford at googlemail dot com>]

Thanks for the update.

Chung-Lin Tang <cltang@codesourcery.com> writes:
> As for the issue of making __builtin_thread_pointer()
> target-independent, while it's possible, it seems that most such
> builtins are functionality that lends to a machine-independent
> implementation when no target-hooks are provided. A thread pointer
> builtin does not seem to be one of those.

Right.  __builtin_thread_pointer() is more like __builtin_return_address(),
__builtin_saveregs(), etc.  The fact that it belongs to the smaller set
of buitins with explicitly target-dependent implementations than the larger
set of builtins with "target-independent" implementations doesn't matter
though.  The point is that we're deliberately using the same name and
interface across targets, rather than things like __builtin_mips_thread_pointer.

Having a target hook to return the thread pointer makes perfect
sense IMO.

> (2) I have included changes in config/mips/t-linux64 to build a MIPS16
> libgcc. MULTILIB_OSDIRNAMES has been modified to use the mapping style,
> to make '-mabi=32 -mips16' a properly linking set of options. This
> should create the appropriate conditions for committing the MIPS16
> libgcc, libgomp changes.

One problem with doing this unconditionally is that, for things like
--with-arch=octeon, we'll end up trying to build MIPS16 OCTEON libraries.
It might (or might not) build without complaint, but it doesn't make
much sense.  We probably need to implement --with-multilib-list and
only include mips16 if explicitly asked.  (In future, it would be
nice to have the ABIs selected in the same way, but that's very much
a separate change.)

Just to check, with this set-up, "-mabi=32 -mips16" selects the MIPS16
multilibs for GCC libraries, but uses the normal /lib etc. directories
for system libraries.  Is that right?  (Genuine question.  I've never
tried this fancy form of MULTILIB_OSDIRNAMES myself.)

> (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).

Thanks,
Richard