[lld] r249340 - Create R_X86_64_RELATIVE when needed.

[Hal Finkel via llvm-commits]

----- Original Message -----
> From: "Rafael Espíndola" <rafael.espindola at gmail.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "llvm-commits" <llvm-commits at lists.llvm.org>
> Sent: Friday, October 16, 2015 4:58:14 PM
> Subject: Re: [lld] r249340 - Create R_X86_64_RELATIVE when needed.
> 
> >> Probably yes (not familiar with TOC). I guess another way of
> >> saying
> >> it
> >> is that these are input relocations that don't require a "full"
> >> dynamic relocation. If nothing else requires it, we end up with a
> >> getRelativeReloc(). Returning false will force a dynamic
> >> relocation
> >> to
> >> be created.
> >
> > What does "require" a relocation mean?
> 
> Causes one to be added to the dynamic table.
> 
> 
> > This might depend on your definition of relative. First, we have
> > relocations like R_PPC64_ADDR32, which are not size_t, and should
> > error if they overflow. If you assume that a shared library might
> > appear anywhere in the 64-bit address space (and not just in the
> > lower 2^32 bytes), then this is indeed dangerous.
> >
> > But then we have relocations like: R_PPC64_ADDR16_LO,
> > R_PPC64_ADDR16_HA, R_PPC64_ADDR16_HIGHERA and
> > R_PPC64_ADDR16_HIGHESTA, which can be used to piece together an
> > address like this (from the PPC64 ELF v1 ABI spec):
> >
> >     lis   r3,SYM at highesta
> >     ori   r3,SYM at highera
> >     sldi  r3,r3,32
> >     oris  r3,r3,SYM at ha
> >     ld    r4,SYM at l(r3)
> >
> > each of these represents a part of an absolute address, but each is
> > less than size_t.
> 
> But none of the is relative, right?  The first one for example has an
> expression of "#lo(S + A)". If there is a relocation with an
> expression of "#lo(S + A - P)", than the assumption we currently have
> is broken.

Now I'm confused. I thought that it was the absolute relocations that we assume were size_t-sized, and thus would get a getRelativeReloc()? This is because they're absolute, but only relative to the base load address of the library. '#lo(S + A)' is neither relative nor size_t-sized. It is also true, that code that does this is not PIC, so maybe this is fine (do we even support creating non-PIC shared libraries?).

 -Hal

> 
> Cheers,
> Rafael
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory