Revision tags: llvmorg-3.6.0-rc2 |
|
#
2658554a |
| 19-Jan-2015 |
Rafael Espindola <rafael.espindola@gmail.com> |
Add r224985 back with fixes.
The fixes are to note that AArch64 has additional restrictions on when local relocations can be used. In particular, ld64 requires that relocations to cstring/cfstrings
Add r224985 back with fixes.
The fixes are to note that AArch64 has additional restrictions on when local relocations can be used. In particular, ld64 requires that relocations to cstring/cfstrings use linker visible symbols.
Original message:
In an assembly expression like
bar: .long L0 + 1
the intended semantics is that bar will contain a pointer one byte past L0.
In sections that are merged by content (strings, 4 byte constants, etc), a single position in the section doesn't give the linker enough information. For example, it would not be able to tell a relocation must point to the end of a string, since that would look just like the start of the next.
The solution used in ELF to use relocation with symbols if there is a non-zero addend.
In MachO before this patch we would just keep all symbols in some sections.
This would miss some cases (only cstrings on x86_64 were implemented) and was inefficient since most relocations have an addend of 0 and can be represented without the symbol.
This patch implements the non-zero addend logic for MachO too.
llvm-svn: 226503
show more ...
|
Revision tags: llvmorg-3.6.0-rc1 |
|
#
7244bb3c |
| 14-Jan-2015 |
Rafael Espindola <rafael.espindola@gmail.com> |
Revert "Add r224985 back with two fixes."
This reverts commit r225644 while I debug a regression.
llvm-svn: 226022
|
#
d9c3e308 |
| 12-Jan-2015 |
Rafael Espindola <rafael.espindola@gmail.com> |
Add r224985 back with two fixes.
One is that AArch64 has additional restrictions on when local relocations can be used. We have to take those into consideration when deciding to put a L symbol in th
Add r224985 back with two fixes.
One is that AArch64 has additional restrictions on when local relocations can be used. We have to take those into consideration when deciding to put a L symbol in the symbol table or not.
The other is that ld64 requires the relocations to cstring to use linker visible symbols on AArch64.
Thanks to Michael Zolotukhin for testing this!
Remove doesSectionRequireSymbols.
In an assembly expression like
bar: .long L0 + 1
the intended semantics is that bar will contain a pointer one byte past L0.
In sections that are merged by content (strings, 4 byte constants, etc), a single position in the section doesn't give the linker enough information. For example, it would not be able to tell a relocation must point to the end of a string, since that would look just like the start of the next.
The solution used in ELF to use relocation with symbols if there is a non-zero addend.
In MachO before this patch we would just keep all symbols in some sections.
This would miss some cases (only cstrings on x86_64 were implemented) and was inefficient since most relocations have an addend of 0 and can be represented without the symbol.
This patch implements the non-zero addend logic for MachO too.
llvm-svn: 225644
show more ...
|
#
04b37c40 |
| 06-Jan-2015 |
Lang Hames <lhames@gmail.com> |
Revert r225048: It broke ObjC on AArch64.
I've filed http://llvm.org/PR22100 to track this issue.
llvm-svn: 225228
|
#
54b435ec |
| 31-Dec-2014 |
Rafael Espindola <rafael.espindola@gmail.com> |
Add r224985 back with a fix.
The issues was that AArch64 has additional restrictions on when local relocations can be used. We have to take those into consideration when deciding to put a L symbol i
Add r224985 back with a fix.
The issues was that AArch64 has additional restrictions on when local relocations can be used. We have to take those into consideration when deciding to put a L symbol in the symbol table or not.
Original message:
Remove doesSectionRequireSymbols.
In an assembly expression like
bar: .long L0 + 1
the intended semantics is that bar will contain a pointer one byte past L0.
In sections that are merged by content (strings, 4 byte constants, etc), a single position in the section doesn't give the linker enough information. For example, it would not be able to tell a relocation must point to the end of a string, since that would look just like the start of the next.
The solution used in ELF to use relocation with symbols if there is a non-zero addend.
In MachO before this patch we would just keep all symbols in some sections.
This would miss some cases (only cstrings on x86_64 were implemented) and was inefficient since most relocations have an addend of 0 and can be represented without the symbol.
This patch implements the non-zero addend logic for MachO too.
llvm-svn: 225048
show more ...
|
#
d4da9040 |
| 31-Dec-2014 |
Rafael Espindola <rafael.espindola@gmail.com> |
Revert "Remove doesSectionRequireSymbols."
This reverts commit r224985.
I am investigating why it made an Apple bot unhappy.
llvm-svn: 225044
|
#
b22d5aa4 |
| 30-Dec-2014 |
Rafael Espindola <rafael.espindola@gmail.com> |
Remove doesSectionRequireSymbols.
In an assembly expression like
bar: .long L0 + 1
the intended semantics is that bar will contain a pointer one byte past L0.
In sections that are merged by conte
Remove doesSectionRequireSymbols.
In an assembly expression like
bar: .long L0 + 1
the intended semantics is that bar will contain a pointer one byte past L0.
In sections that are merged by content (strings, 4 byte constants, etc), a single position in the section doesn't give the linker enough information. For example, it would not be able to tell a relocation must point to the end of a string, since that would look just like the start of the next.
The solution used in ELF to use relocation with symbols if there is a non-zero addend.
In MachO before this patch we would just keep all symbols in some sections.
This would miss some cases (only cstrings on x86_64 were implemented) and was inefficient since most relocations have an addend of 0 and can be represented without the symbol.
This patch implements the non-zero addend logic for MachO too.
llvm-svn: 224985
show more ...
|
Revision tags: llvmorg-3.5.1, llvmorg-3.5.1-rc2, llvmorg-3.5.1-rc1, llvmorg-3.5.0, llvmorg-3.5.0-rc4, llvmorg-3.5.0-rc3 |
|
#
752b91bd |
| 10-Aug-2014 |
Joerg Sonnenberger <joerg@bec.de> |
If available, pass down the Fixup object to EvaluateAsRelocatable. At least on PowerPC, the interpretation of certain modifiers depends on the context they appear in.
llvm-svn: 215310
|
Revision tags: llvmorg-3.5.0-rc2 |
|
#
1f8930e3 |
| 25-Jul-2014 |
Benjamin Kramer <benny.kra@googlemail.com> |
Run sort_includes.py on the AArch64 backend.
No functionality change.
llvm-svn: 213938
|
Revision tags: llvmorg-3.5.0-rc1 |
|
#
2a30d788 |
| 18-Jun-2014 |
Craig Topper <craig.topper@gmail.com> |
Replace some assert(0)'s with llvm_unreachable.
llvm-svn: 211141
|
#
3b0846e8 |
| 24-May-2014 |
Tim Northover <tnorthover@apple.com> |
AArch64/ARM64: move ARM64 into AArch64's place
This commit starts with a "git mv ARM64 AArch64" and continues out from there, renaming the C++ classes, intrinsics, and other target-local objects for
AArch64/ARM64: move ARM64 into AArch64's place
This commit starts with a "git mv ARM64 AArch64" and continues out from there, renaming the C++ classes, intrinsics, and other target-local objects for consistency.
"ARM64" test directories are also moved, and tests that began their life in ARM64 use an arm64 triple, those from AArch64 use an aarch64 triple. Both should be equivalent though.
This finishes the AArch64 merge, and everyone should feel free to continue committing as normal now.
llvm-svn: 209577
show more ...
|