* Maciej W. Rozycki: > On Mon, 3 Oct 2016, Florian Weimer wrote: > >> > 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. >> >> GHC produces objects which need -mxgot. > > Ouch, what a waste of memory! There might be ways to cut down the number of relocations. >> The GCC documentation doesn't say anything about incompatibilities >> between -mxgot and -mno-xgot. Will this result in a linker failure at >> least? > > The incompatibility is I believe noted in the psABI documents; it > wouldn't hurt mentioning it in compiler documentation, although I do hope > you realise it is not meant to stand for ABI documentation. > > You won't always get a link error as the incompatibility is not inherent > (which is why I've noted it could be supported although nobody has cared > to make it); if a link does succeed, then the binary will work correctly. Okay, that's very good to know. So we can deal with this once we hit the issue. > The thing is as soon as GOT expands beyond the 16-bit limit entries > outside this limit will become out of reach for 16-bit GOT references > (R_MIPS_GOT16 relocations in the o32 ABI; R_MIPS_GOT_DISP and > R_MIPS_GOT_PAGE relocations in the new ABIs, although for brevity I'll use > R_MIPS_GOT16 from now on with an implicit reference to any of these) and > we currently do nothing to arrange entries in the GOT such that these > referred with R_MIPS_GOT16 relocations fall within the 16-bit limit if > possible. Yes, I expected something like that as the cause. As long as ld detects this when it happens, I'm fine with it for now. > This raises a question however: why do you need it in the first place? > The only case where multi-got does not work is where you have a single > object (.o) file which requires more than 16378 GOT entries (8188 in the > n64 ABI case). A GOT entry is required per each individual global symbol > and per each 64kB chunk of local (static) symbols -- do you really have > such a huge object file? Perhaps you could split the source so that > multiple objects are created instead? Or group multiple related variables in a struct. There are likely quite a few ways GHC could generate code leading to improved relocations because the DSOs it builds do not have a stable ABI anyway. But I bet it's not on the GHC developers' radar screen today because other platforms have less stringent limits (but would benefit from the RSS reduction as well). You'll see that in Fedora eventually. My question was prompted by a Debian build failure without -mxgot.
