On Mon, 3 Oct 2016, Florian Weimer wrote: > >> 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). > > > > I take it they don't support multi-GOT then, right? > > GHC is used in a mode which generates C code, which is then compiled > using GCC. (This is why Debian could apply the -mxgot workaround so > quicky.) Hmm, thanks for sharing a Debian bug report reference -- so it's the Glasgow Haskell Compiler you've been referring to rather than the Green Hills Compiler I understood thoughout our discussion so far. That changes things a bit, I wasn't considering you had a generated C source and rather I understood you had an interlinking problem as the Green Hills Compiler certainly makes MIPS object code. > >> You'll see that in Fedora eventually. My question was prompted by a > >> Debian build failure without -mxgot. > > > > So what did fail to build then? That's ultimately what the question I > > asked boils down to. > > This is the Debian bug report about the build failure: > > <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832824> Thanks; if Debian developers want the linker to be updated such that `-mxgot' works reliably with `-mno-xgot' code, then please file an enhancement request with <https://sourceware.org/bugzilla/>; of course any patch proposal will vastly speed up the handling of such a request. Ultimately we may have to support mixing multi-GOT and XGOT, though obviously only the primary GOT will have to have special handling for XGOT; any R_MIPS_GOT_HI16/R_MIPS_GOT_LO16 relocation pairs resolving outside XGOT will calculate like R_MIPS_GOT16, i.e. the high part will be zero. HTH, Maciej
