On Thu, 06 Jan 2011 09:47:49 -0800 Richard Henderson <r...@redhat.com> wrote:
> On 01/06/2011 01:17 AM, Karel Gardas wrote: > > BTW: This is on GCC Compile Farm IA64 machine. Now my question is: how > > to solve this issue? Does GCC already support something Intel > > discusses in 2008 here: > > http://software.intel.com/en-us/articles/short-data-segment-overflow-error-on-linux-64-on-itaniumr-architecture/ > > -- i.e. using huge memory model for static data? > > No, we don't. > > I thought for a moment that you might be able to use one of the > standalone (aka kernel/rom) modes, such as -mno-pic or -mauto-pic, > which would certainly solve the got-overflow problem above, but > unfortunately they also change the function calling convention. > You'd not be able to link with libc. > > It should not be hard to add such support to gcc, if you have an > interest. All the appropriate relocations are already defined > in the spec and accepted by the assembler. Hello Richard! GHC (haskell compiler) generates very large C sources with lots of relocations (-G0 does not help) when GHC builds itself. So I would like to have "large data segment" feature! Can you elaborate what exactly needs to be implemented? From what I see: 0. We need additional flag for gcc: let's call it -mhuge-pic 1. We need to force GCC to generate any GP (r1) offsets. Seems, we need to emit some kind of LX instruction to compute absolute data offset in a separate register. What kind of relocation should be that to have ability to mix them with stock ones? 2. We need to fix binutils to be able to relax sections with usual and "huge" types of access to GP. Am I Right? Thank you! -- Sergei
signature.asc
Description: PGP signature
