Re: IA64: short data segment overflowed issue

[Sergei Trofimovich <slyich at gmail dot com>]

On Thu, 06 Jan 2011 09:47:49 -0800
Richard Henderson <rth@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

Attachment: signature.asc
Description: PGP signature