Commit Graph

12 Commits

Author SHA1 Message Date
Fangrui Song d4306e90cb [ELF][X86] Allow PT_LOAD to have overlapping p_offset ranges on EM_X86_64
Port the D64906 technique to EM_X86_64.

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

llvm-svn: 371958
2019-09-16 07:05:34 +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
Fangrui Song 07f8daf05e [ELF] Simplify RelRo, TLS, NOBITS section ranks and make RW PT_LOAD start with RelRo
Old: PT_LOAD(.data | PT_GNU_RELRO(.data.rel.ro .bss.rel.ro) | .bss)
New: PT_LOAD(PT_GNU_RELRO(.data.rel.ro .bss.rel.ro) | .data .bss)

The placement of | indicates page alignment caused by PT_GNU_RELRO. The
new layout has simpler rules and saves space for many cases.

Old size: roundup(.data) + roundup(.data.rel.ro)
New size: roundup(.data.rel.ro + .bss.rel.ro) + .data

Other advantages:

* At runtime the 3 memory mappings decrease to 2.
* start(PT_TLS) = start(PT_GNU_RELRO) = start(RW PT_LOAD). This
  simplifies binary manipulation tools.
  GNU strip before 2.31 discards PT_GNU_RELRO if its
  address is not equal to the start of its associated PT_LOAD.
  This has been fixed by https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f2731e0c374e5323ce4cdae2bcc7b7fe22da1a6f
  But with this change, we will be compatible with GNU strip before 2.31
* Before, .got.plt (non-relro by default) was placed before .got (relro
  by default), which made it impossible to have _GLOBAL_OFFSET_TABLE_
  (start of .got.plt on x86-64) equal to the end of .got (R_GOT*_FROM_END)
  (https://bugs.llvm.org/show_bug.cgi?id=36555). With the new ordering, we
  can improve on this regard if we'd like to.

Reviewers: ruiu, espindola, pcc

Subscribers: emaste, arichardson, llvm-commits, joerg, jdoerfert

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

llvm-svn: 356117
2019-03-14 03:47:45 +00:00
Rafael Espindola 0e4df539fa Change the default of --apply-dynamic-relocs.
When using Elf_Rela every tool should use the addend in the
relocation.

We have --apply-dynamic-relocs to work around bugs in tools that don't
do that.

The default value of --apply-dynamic-relocs should be false to make
sure these bugs are more easily found in the future.

llvm-svn: 324264
2018-02-05 19:39:04 +00:00
Peter Smith 64f65b02d2 [ELF] Implement --[no-]apply-dynamic-relocs option.
When resolving dynamic RELA relocations the addend is taken from the
relocation and not the place being relocated. Accordingly lld does not
write the addend field to the place like it would for a REL relocation.
Unfortunately there is some system software, in particlar dynamic loaders
such as Bionic's linker64 that use the value of the place prior to
relocation to find the offset that they have been loaded at. Both gold
and bfd control this behavior with the --[no-]apply-dynamic-relocs option.
This change implements the option and defaults it to true for compatibility
with gold and bfd.

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

llvm-svn: 324221
2018-02-05 10:15:08 +00:00
Peter Collingbourne 628ec9f193 ELF: Place relro sections after non-relro sections in r/w segment.
This is in preparation for my next change, which will introduce a relro
nobits section. That requires that relro sections appear at the end of the
progbits part of the r/w segment so that the relro nobits section can appear
contiguously.

Because of the amount of churn required in the test suite, I'm making this
change separately.

llvm-svn: 291523
2017-01-10 01:21:30 +00:00
Rafael Espindola 7229496787 When using Rela, don't write the addend to the output section.
The Elf_Rela has an explicit addend. It doesn't need the addend to be
written to the section being relocated.

Since relative relocations are very common in the output, this is a
noticeable speedup. The results I got were

chromium
  master 4.778149487
  patch  4.761120792 0.996436131802
chromium fast
  master 1.896253636
  patch  1.840990582 0.970856718241
the gold plugin
  master 0.399337811
  patch  0.392279276 0.982324401032
clang
  master 0.666873675
  patch  0.665895708 0.998533504865
llvm-as
  master 0.037101095
  patch  0.037123149 1.00059442989
the gold plugin fsds
  master 0.422473396
  patch  0.414192879 0.980399909016
clang fsds
  master 0.747302008
  patch  0.744843964 0.996710775599
llvm-as fsds
  master 0.033146245
  patch  0.033064531 0.997534743377
scylla
  master 4.08857525
  patch  4.082245184 0.998451767275

llvm-svn: 269417
2016-05-13 14:15:37 +00:00
Rafael Espindola cceacd7113 Don't depend on lld creating relocations in ro segments.
We currently don't do a good job of diagnosing inputs that would require
dynamic relocations to be applied to read only segments.

I am about to improve lld in that area, but unfortunately we developed
tests that depend on the current behavior.

To make clear what is actually changing, this first patch just updates
tests to not depend on the current behavior. In most cases this just
means using a rw section instead of a ro one, but that unfortunately
changes many addresses.

llvm-svn: 268145
2016-04-30 00:49:10 +00:00
Rui Ueyama 890ce0c188 Do not produce broken debug info.
r267917 produces corrupted debug info because it didn't apply
relocations to right offsets.

llvm-svn: 267979
2016-04-29 03:21:08 +00:00
Rui Ueyama 2b6fb80384 Skip scanRelocs for non-alloc sections.
Relocations against sections with no SHF_ALLOC bit are R_ABS relocations.
Currently we are creating Relocations vector for them, but that is wasteful.
This patch is to skip vector construction and to directly apply relocations
in place.

This patch seems to be pretty effective for large executables with debug info.
r266158 (Rafael's patch to change the way how we apply relocations) caused a
temporary performance degradation for such executables, but this patch makes
it even faster than before.

Time to link clang with debug info (output size is 1070 MB):

  before r266158: 15.312 seconds (0%)
  r266158:        17.301 seconds (+13.0%)
  Head:           16.484 seconds (+7.7%)
  w/patch:        13.166 seconds (-14.0%)

Differential Revision: http://reviews.llvm.org/D19645

llvm-svn: 267917
2016-04-28 18:42:04 +00:00
Rafael Espindola 91641d9947 Add a few more cases to this test.
It now documents how we currently handle relocations for
alloc/non-alloc.

llvm-svn: 266141
2016-04-12 22:08:23 +00:00
Rafael Espindola 2d390b6c8b Add a test for relocations in non alloc sections.
We already got this right, but we were not testing it.

llvm-svn: 265471
2016-04-05 21:27:30 +00:00