Commit Graph

12 Commits

Author SHA1 Message Date
Tobias Hieta 87383e408d [ELF][ARM] Increase default max-page-size from 4096 to 6536
See http://lists.llvm.org/pipermail/llvm-dev/2020-April/140549.html

For the record, GNU ld changed to 64k max page size in 2014
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=7572ca8989ead4c3425a1500bc241eaaeffa2c89
"[RFC] ld/ARM: Increase maximum page size to 64kB"

Android driver forced 4k page size in AArch64 (D55029) and ARM (D77746).

A binary linked with max-page-size=4096 does not run on a system with a
higher page size configured. There are some systems out there that do
this and it leads to the binary getting `Killed!` by the kernel.

In the non-linker-script cases, when linked with -z noseparate-code
(default), the max-page-size increase should not cause any size
difference. There may be some VMA usage differences, though.

Reviewed By: psmith, MaskRay

Differential Revision: https://reviews.llvm.org/D77330
2020-04-18 08:19:45 -07:00
Fangrui Song f0374e7db2 [test] lld/test/: change llvm-objdump single-dash long options to double-dash options 2020-03-15 17:48:36 -07:00
Fangrui Song 71e2ca6e32 [llvm-objdump] -d: print `00000000 <foo>:` instead of `00000000 foo:`
The new behavior matches GNU objdump. A pair of angle brackets makes tests slightly easier.

`.foo:` is not unique and thus cannot be used in a `CHECK-LABEL:` directive.
Without `-LABEL`, the CHECK line can match the `Disassembly of section`
line and causes the next `CHECK-NEXT:` to fail.

```
Disassembly of section .foo:

0000000000001634 .foo:
```

Bdragon: <> has metalinguistic connotation. it just "feels right"

Reviewed By: rupprecht

Differential Revision: https://reviews.llvm.org/D75713
2020-03-05 18:05:28 -08:00
Fangrui Song 024bf27ddf [ELF][ARM] Allow PT_LOAD to have overlapping p_offset ranges on EM_ARM
Port the D64906 technique to ARM. It deletes 3 alignments at
PT_LOAD boundaries for the default case: the size of an arm binary
decreases by at most 12kb.

Reviewed By: grimar

Differential Revision: https://reviews.llvm.org/D66749

llvm-svn: 370049
2019-08-27 11:52:36 +00:00
Fangrui Song 5387c2cd17 [llvm-objdump] Print newlines before and after "Disassembly of section ...:"
This improves readability and the behavior is consistent with GNU objdump.

The new test test/tools/llvm-objdump/X86/disassemble-section-name.s
checks we print newlines before and after "Disassembly of section ...:"

Differential Revision: https://reviews.llvm.org/D61127

llvm-svn: 359668
2019-05-01 10:40:48 +00:00
Fangrui Song b159906a9a [test] Change llvm-readobj -long-option to --long-option or well-known short options. NFC
Also change some options that have different semantics (cause confusion) in llvm-readelf mode:

-s => -S
-t => --symbols
-sd => --section-data

llvm-svn: 359651
2019-05-01 05:49:01 +00:00
Peter Collingbourne 5c902845e5 Revert r327248, "For most Targets the _GLOBAL_OFFSET_TABLE_ symbol is expected to be at"
This change broke ARM code that expects to be able to add
_GLOBAL_OFFSET_TABLE_ to the result of an R_ARM_REL32.

I will provide a reproducer on llvm-commits.

llvm-svn: 327688
2018-03-16 01:01:44 +00:00
Peter Smith 18aa0be36e For most Targets the _GLOBAL_OFFSET_TABLE_ symbol is expected to be at
the start of the .got.plt section so that _GLOBAL_OFFSET_TABLE_[0] =
reserved value that is by convention the address of the dynamic section.
Previously we had defined _GLOBAL_OFFSET_TABLE_ as either the start or end
of the .got section with the intention that the .got.plt section would
follow the .got. However this does not always hold with the current
default section ordering so _GLOBAL_OFFSET_TABLE_[0] may not be consistent
with the reserved first entry of the .got.plt.

X86, X86_64, Arm and AArch64 will use the .got.plt. Mips and Power use .got

Fixes PR36555

Differential Revision: https://reviews.llvm.org/D44259

llvm-svn: 327248
2018-03-11 20:58:18 +00:00
George Rimar d46753e421 [ELF] - Do --hash-style=both by default.
Its PR34712,

GNU linkers recently changed default values to "both" of "sysv".
Patch do the same for all targets except MIPS, where .gnu.hash
section is not yet supported.

Code suggested by Rui Ueyama.

Differential revision: https://reviews.llvm.org/D38407

llvm-svn: 315051
2017-10-06 09:37:44 +00:00
Peter Smith 113a59e7db [ELF] Define _GLOBAL_OFFSET_TABLE_ symbol relative to .got
On many architectures gcc and clang will recognize _GLOBAL_OFFSET_TABLE_ - .
and produce a relocation that can be processed without needing to know the
value of _GLOBAL_OFFSET_TABLE_. This is not always the case; for example ARM
gcc produces R_ARM_BASE_PREL but clang produces the more general
R_ARM_REL32 to _GLOBAL_OFFSET_TABLE_. To evaluate this relocation
correctly _GLOBAL_OFFSET_TABLE_ must be defined to be the either the base of
the GOT or end of the GOT dependent on architecture..

If/when llvm-mc is changed to recognize _GLOBAL_OFFSET_TABLE_ - . this
change will not be necessary for new objects. However there may still be
old objects and versions of clang.

Differential Revision: https://reviews.llvm.org/D34355

llvm-svn: 306282
2017-06-26 10:22:17 +00:00
Rui Ueyama 5fc84a1828 Remove string table offsets from tests.
<N> where "foo (<N>)" is the offset of string "foo" in the string table.

llvm-svn: 285751
2016-11-01 21:26:28 +00:00
Peter Smith 8646ced053 Initial support for ARM in lld.
Add support for an ARM Target and the initial set of relocations
    and PLT entries that are necessary for an ARM only hello world to
    link. This has been tested against an ARM only sysroot from the
    4.2.0 CodeSourcery Lite release.
    
    Tests have been added to test/ELF for the support that has been
    implemented.
    
    Main limitations:
    - No Thumb support
    - Relocations incomplete
    - No C++ exceptions support
    - No TLS support
    - No range extension or interworking veneer (thunk) support
    - No Build Attribute support
    - No Big-endian support
    
    The deprecated relocations R_ARM_PLT32 and R_ARM_PC24 have been
    implemented as these are used by the 4.2.0 CodeSourcery Lite release.

llvm-svn: 271993
2016-06-07 09:31:52 +00:00