On Thu, 20 Jan 2011 17:27:14 -0800 Richard Henderson <r...@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
signature.asc
Description: PGP signature
