diff options
| author | Hal Finkel <hfinkel@anl.gov> | 2015-10-16 22:11:05 +0000 |
|---|---|---|
| committer | Hal Finkel <hfinkel@anl.gov> | 2015-10-16 22:11:05 +0000 |
| commit | c91740616ae58b162ec35789c702deb1d2cdeaa5 (patch) | |
| tree | 4ef7ed9eedda7ec762b7bedefb5b1551f61ca5e7 /clang/lib/Frontend/CompilerInvocation.cpp | |
| parent | 0fdd572763a3fd1503c31ac9ac89b8bf04065040 (diff) | |
| download | llvm-c91740616ae58b162ec35789c702deb1d2cdeaa5.zip llvm-c91740616ae58b162ec35789c702deb1d2cdeaa5.tar.gz llvm-c91740616ae58b162ec35789c702deb1d2cdeaa5.tar.bz2 | |
[ELF2] Don't create RelativeReloc for weak undef symbols
When we have a R_PPC64_ADDR64 for a weak undef symbol, which thus resolves to
0, and we're creating a shared library, we need to make sure that it stays 0
(because code that conditionally calls the weak function tests for this).
Unfortunately, we were creating a R_PPC64_RELATIVE for these relocation
targets, making the address of the undefined weak symbol equal to the base
address of the shared library (which is non-zero). In general, we should not be
creating RelativeReloc relocs for undef weak symbols.
llvm-svn: 250558
Diffstat (limited to 'clang/lib/Frontend/CompilerInvocation.cpp')
0 files changed, 0 insertions, 0 deletions