This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Fix for s390_elf_cons.
- To: Martin Schwidefsky <schwidefsky at de dot ibm dot com>
- Subject: Re: Fix for s390_elf_cons.
- From: Alan Modra <amodra at bigpond dot net dot au>
- Date: Tue, 31 Jul 2001 10:49:22 +0930
- Cc: binutils at gcc dot gnu dot org
- References: <OF41C62CF5.959C060E-ONC1256A99.0065CD50@de.ibm.com>
On Mon, Jul 30, 2001 at 08:38:43PM +0200, Martin Schwidefsky wrote:
>
> >This leaves me wondering why your plt relocs are marked pcrel. It seems
> >to me that they ought to be non-pcrel since you are already subtracting
> >off a location-relative value with "-.LT0_0". Alternatively, the correct
> >syntax for a pc-relative relocation would be
> >
> > .long printk@PLT + (. - .LT0_0)
> >
> >since a pc-relative reloc implicitly subtracts "." from the symbol value.
>
> Hmm, but .LT0_0 is a local label for the start of the literal pool. What
> you have is
>
> .long (printk@PLT - .) + (. - .LT0_0)
>
> The second part is an absolute addend and the first part is the pc relative
> distance to the plt of printk. Does this makes sense?
Somewhat :) I'm claiming that the subtraction of the current location is
implicit since you are using a pc-relative relocation.
Consider an analogy with pcrel call insns on many architectures. We
write "call foo", which generates a pcrel reloc against foo with an
implicit subtraction of ".". We don't write "call foo - .". On x86,
which uses a pcrel plt reloc, we have "call foo@PLT" too, not
"call foo@PLT - ." This extends to ".long foo@PLT" if you want a
pcrel plt reloc.
Hmm, thinking about it some more, you do want pcrel .plt relocs, it's
just that the syntax you are using is a little unusual.
Alan