This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


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

Re: Fix for s390_elf_cons.


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


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