On Mon, 3 Oct 2016, Matthew Fortune wrote: > > It looks like -mxgot has a similar impact on MIPS as using -fPIC > > (instead of -fpic) on other architectures. > > > > Why wasn't the -fpic/-fPIC distinction carried over to MIPS? > > Much of the history here is probably folklore and guesswork but for > my understanding is that MIPS has three levels of 'pic'. > > MIPS PIC code is really controlled by -mabicalls and -mshared which > I assume originate from the MIPS-pro days. > > -fpic is simply set to imply -mabicalls and -mshared which is where > everything gets far more confusing (but let's not get into that > unless we have to) > > The reason there is no -fPIC is probably a conscious decision as > MIPS has 'multi-got' that allows the small -fpic model to scale to > most situations. > > -mxgot (aka big-got) is however a good match for -fPIC as it is a > model guaranteed to work irrespective of how big the GOT is. For MIPS `-fPIC' is an alias to `-fpic' and the actual reason is these options have only been retrofitted to the MIPS target when non-PIC support has been added to shared-library (as opposed to bare-metal) targets. The original MIPS SVR4 psABI mandated all code to be PIC, even executables, and the model chosen was controlled with the `-mxgot' option, hardly ever used, due to the code bloat implied and link-time incompatibility with the default `-mno-xgot' code. The latter could be rectified to some extent by a specific GOT entry ordering, but with the advent of multi-GOT there was little incentive to actually implement it. So once non-PIC support has been added to shared-library targets, back in 2008 only (i.e. 14 years from the inception of the MIPS/Linux port, almost twice as much time as has passed from the addition of the feature till now; to say nothing of IRIX support; cf. binutils commit 861fb55ab50a, GCC commit 139170) a choice was made not to change the existing arrangement for PIC code. I think given that lots of software just blindly uses `-fPIC' in their Makefiles rather than switching between `-fpic' and `-fPIC' somehow (how?) and that code built with either of `-mno-xgot' and `-mxgot' is incompatible with each other it was a good choice. I think `libtool' could cope with that somehow although obviously all the world is not `libtool'. NB we still have all code PIC for the new ABIs (n64 and n32), in which case all of `-fpic'/`-fPIC'/`-fno-pic'/`-fno-PIC' are no-ops, and GCC can be configured for the old ABI (o32) to default to PIC executables as well, in which case these are no-ops too, unless overridden with `-mplt'. > I do have a report to deal with about -fPIC and the value it sets > for __PIC__ because it always sets '1' due to not supporting -fPIC. > It is tempting to just make -fPIC imply -mxgot and set __PIC__ to 2 > but it will lead to bloated code in a number of cases where > multi-got is sufficient. I'd rather say it would break almost everything. Maciej
