This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: IA64: short data segment overflowed issue


On Thu, 20 Jan 2011 17:27:14 -0800
Richard Henderson <rth@redhat.com> wrote:

> On 01/20/2011 01:26 PM, Sergei Trofimovich wrote:
> > 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.
> 
> Depending on how Haskell programs are built, it may be better
> to avoid the GOT entirely.  E.g.
> 
>   -mcmodel=large
> 
> a-la the x86_64 port.  This generates full 64-bit absolute
> relocations.  For ia64 code this would look like
> 
> 	movl	r32 = foo#
> 
>   Offset          Info           Type           Sym. Value    Sym. Name + Addend
> 000000000002  000400000023 R_IA64_IMM64      0000000000000000 foo + 0
> 
> Of course, you wouldn't put this code into a shared library.
> For that you really would want a 64-bit GPREL offset.  E.g.
> 
> 	movl	r32 = @gprel(foo)
> 	add	r32 = r32, r1
> 
>   Offset          Info           Type           Sym. Value    Sym. Name + Addend
> 000000000002  00040000002b R_IA64_GPREL64I   0000000000000000 foo + 0
> 
> Since both of these assemble now, really doubt there's any 
> binutils work that needs to be done.
> 
> What you'd have to do is add some command-line switches (and perhaps
> clean up the ones that are there wrt code models), and adjust the
> code in ia64_expand_load_address to handle your new options.  It really
> shouldn't be very difficult.

Having dropped the ball years ago I've accidentally got it fixed
by using gprel imm64 instead of failed gprel imm22:

    https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02193.html

It was enough for both original bug and ghc build on ia64.

-- 

  Sergei

Attachment: signature.asc
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]