This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [PATCH] x86-64: support newer relocation types
- From: Jan Hubicka <jh at suse dot cz>
- To: Jan Beulich <JBeulich at novell dot com>
- Cc: jh at suse dot cz, binutils at sources dot redhat dot com, hubicka at ucw dot cz
- Date: Thu, 16 Jun 2005 13:20:03 +0200
- Subject: Re: [PATCH] x86-64: support newer relocation types
- References: <s2b0cc2d.097@lyle.provo.novell.com>
> >> 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