[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