Home Original page

[PATCH] x86-64: support newer relocation types

Jan Hubicka jh@suse.cz
Thu Jun 16 11:20:00 GMT 2005 
> >> If so, this would seem to be an unrelated change, as the GOTPC32 reloc in my
> >>patch is handled exactly like the i386 one (which of course is very broken, but
> >>obviously cannot be fixed). Or maybe I don't see how you would see
> >>BFD_RELOC_32_PCREL to end up here.
> >
> >i386 GOT relocation is different from GOTPC32 in a way that one is IP
> >relative and other not.
> >I386 way of encoding GOT relocation is:
> >        addl    $_GLOBAL_OFFSET_TABLE_+[.-.L2], %ebx
> >While for x86-64 we want something like:
> >	leaq    _GLOBAL_OFFSET_TABLE_(%rip), %rbx
> >So the expression to match needs tobe slightly different.
> 
> While the explanation is only partly right (we're talking about i386's
> GOTPC vs. x86-64's GOTPC32 here, which have identical semantics), it

Oops, sorry.  I forgot that the i386 equivalent also ends up in PC
relative relocation despite the lack of harware support, but anyway I
would like to have the RIP relative syntax instead of having to invent
new labels to encode GOTPC32

> also occured to me that the RIP-relative addressing makes a difference
> here. So I guess I'll have to add such code to the disp parser.
> However, the similar code in the immediate parser doesn't need to be
> changed (because in an immediate there cannot be any RIP-relative).

Even tought I think at least early versions of gas accepted (%rip)
suffix to make immediates IP relative, this probably don't make much
sense here.  We probably would want to use something like
_GLOBAL_OFFSET_TABLE_-. as do for IP relative relocations in unwind
tables, if we ever will use this feature at all...  I think that is
covered by the i386-alike pattern matching, right?

> Hopefully I'll have a revised patch later today...

Thanks!  I've updated the medium model patches for current GCC so I will
give it some testing afterwards.

Honza
> 
> Jan
More information about the Binutils mailing list