maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lld/test/ELF/x86-64-dyn-rel-error.s

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

18 lines
753 B
ArmAsm
Raw Normal View History

Also reject 32 bit dynamic relocs when producing executable. They point to a shared library, so they would still overflow at runtime. llvm-svn: 272303
2016-06-10 04:35:27 +08:00
// REQUIRES: x86
// RUN: llvm-mc -filetype=obj -triple=x86_64-pc-linux %s -o %t.o
// RUN: llvm-mc -filetype=obj -triple=x86_64-pc-linux %p/Inputs/shared.s -o %t2.o
// RUN: ld.lld %t2.o -shared -o %t2.so
[ELF][test] Change -o %t to -o /dev/null if the output is not needed
2020-02-13 13:48:45 +08:00
// RUN: not ld.lld -shared %t.o %t2.so -o /dev/null 2>&1 | FileCheck %s
Also reject 32 bit dynamic relocs when producing executable. They point to a shared library, so they would still overflow at runtime. llvm-svn: 272303
2016-06-10 04:35:27 +08:00
.global _start
_start:
.data
Allow relocations in rw sections to create plt entries. If a relocation cannot be implemented by the dynamic linker and the section is rw, allow creating a plt entry to use as the function address as if the section was ro. This matches bfd and gold. It also matches our behavior with -z notext. llvm-svn: 321430
2017-12-25 03:02:10 +08:00
.long zed
Also reject 32 bit dynamic relocs when producing executable. They point to a shared library, so they would still overflow at runtime. llvm-svn: 272303
2016-06-10 04:35:27 +08:00
[ELF] Remove -Wl,-z,notext hint The hint does not pull its weight: * adding -Wl,-z,notext often won't work (relocation types other than `symbolRel`, e.g. `R_AARCH64_LDST32_ABS_LO12_NC`) * for pure (no assembly) C/C++ projects, the "-fPIC" hint is sufficient
2021-11-01 03:10:42 +08:00
// CHECK: error: relocation R_X86_64_32 cannot be used against symbol 'zed'; recompile with -fPIC
[ELF] - Change way how we handle --noinhibit-exec Previously we handled this option implicitly, only for infering unresolved symbols handling policy. ld man says: "--noinhibit-exec Retain the executable output file whenever it is still usable", and we may want to handle other cases too. Differential revision: https://reviews.llvm.org/D35793 llvm-svn: 309091
2017-07-26 17:46:59 +08:00
[ELF] Simplify processRelocAux and allow a corner-case error After D66007/r369262, if the control flow reaches `if (sym.isUndefined())`, we know: * The relocation is not a link-time constant => symbol is preemptable => Undefined or SharedSymbol * Not an undef weak. * -no-pie. * The symbol type is neither STT_OBJECT nor STT_FUNC. ld.lld --export-dynamic --unresolved-symbols=ignore-all %t.o can satisfy these conditions. Delete the isUndefined() test so that we error `symbol '...' has no type`, because we don't know the type to make the decision to create copy relocation/canonical PLT. llvm-svn: 369271
2019-08-19 23:52:29 +08:00
// RUN: ld.lld --noinhibit-exec %t.o %t2.so -o /dev/null 2>&1 | FileCheck --check-prefix=WARN %s
// RUN: not ld.lld --export-dynamic --unresolved-symbols=ignore-all %t.o -o /dev/null 2>&1 | FileCheck --check-prefix=WARN %s
Rewrite our relocation processing. This splits relocation processing in two steps. First, analyze what needs to be done at the relocation spot. This can be a constant (non preemptible symbol, relative got reference, etc) or require a dynamic relocation. At this step we also consider creating copy relocations. Once that is done we decide if we need a got or a plt entry. The code is simpler IMHO. For example: - There is a single call to isPicRel since the logic is not split among adjustExpr and the caller. - R_MIPS_GOTREL is simple to handle now. - The tracking of what is preemptible or not is much simpler now. This also fixes a regression with symbols being both in a got and copy relocated. They had regressed in r268668 and r268149. The other test changes are because of error messages changes or the order of two relocations in the output. llvm-svn: 322047
2018-01-09 08:13:54 +08:00
[ELF] Replace "symbol '...' has no type" diagnostic with "relocation ... cannot be used against symbol '...'" The "symbol 'foo' has no type" diagnostic tries to inform that copy relocation/canonical PLT entry cannot be used, but the diagnostic is often incorrect and confusing.
2021-11-01 04:12:26 +08:00
// WARN: relocation R_X86_64_32 cannot be used against symbol 'zed'; recompile with -fPIC