[lld] r249340 - Create R_X86_64_RELATIVE when needed.

Hal Finkel via llvm-commits llvm-commits at lists.llvm.org
Fri Oct 16 14:50:19 PDT 2015


----- 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:30:04 PM
> Subject: Re: [lld] r249340 - Create R_X86_64_RELATIVE when needed.
> 
> > I am wondering, for example, whether the .TOC.-relative relocations
> > should be in this list? They're relative, in the sense that they
> > don't require a getRelativeReloc() to be generated.
> 
> 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?

> 
> >>
> >> > Is it true that, for -shared and any relocation for which
> >> > isRelRelative returns false, getRelativeReloc() is generated? If
> >> > not, what other conditions affect when getRelativeReloc() is
> >> > generated?
> >>
> >> I don't think the mapping is that direct.
> >
> > Maybe the thing that needs to be commented is this mapping. It
> > clearly seems to have something to do with the return from
> > isRelRelative, but it is more complicated? getRelativeReloc()
> > needs a size_t-sized relocation target. How do we know when we
> > have one?
> 
> If the relocation is not relative and not size_t sized, there would
> be
> the possibility of overflowing at runtime, no?

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.

Thanks again,
Hal

> 
> Cheers,
> Rafael
> 

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


More information about the llvm-commits mailing list