Thanks for the update. Chung-Lin Tang <clt...@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
