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/i386-merge.s

50 lines
1.2 KiB
ArmAsm
Raw Normal View History

Fix handling of addends on i386. Because of merge sections it is not sufficient to just add them while applying a relocation. llvm-svn: 264863
2016-03-30 20:40:38 +08:00
// REQUIRES: x86
// RUN: llvm-mc -filetype=obj -triple=i386-pc-linux %s -o %t.o
// RUN: ld.lld %t.o -o %t -shared
[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 13:49:01 +08:00
// RUN: llvm-readobj -S --section-data %t | FileCheck %s
Fix handling of addends on i386. Because of merge sections it is not sufficient to just add them while applying a relocation. llvm-svn: 264863
2016-03-30 20:40:38 +08:00
// CHECK: Name: .mysec
// CHECK-NEXT: Type:
// CHECK-NEXT: Flags [
// CHECK-NEXT: SHF_ALLOC
// CHECK-NEXT: SHF_MERGE
// CHECK-NEXT: ]
[ELF] Split RW PT_LOAD on the PT_GNU_RELRO boundary Summary: Based on Peter Collingbourne's suggestion in D56828. Before D56828: PT_LOAD(.data PT_GNU_RELRO(.data.rel.ro .bss.rel.ro) .bss) Old: PT_LOAD(PT_GNU_RELRO(.data.rel.ro .bss.rel.ro) .data .bss) New: PT_LOAD(PT_GNU_RELRO(.data.rel.ro .bss.rel.ro)) PT_LOAD(.data. .bss) The new layout reflects the runtime memory mappings. By having two PT_LOAD segments, we can utilize the NOBITS part of the first PT_LOAD and save bytes for .bss.rel.ro. .bss.rel.ro is currently small and only used by copy relocations of symbols in read-only segments, but it can be used for other purposes in the future, e.g. if a relro section's statically relocated data is all zeros, we can move it to .bss.rel.ro. Reviewers: espindola, ruiu, pcc Reviewed By: ruiu Subscribers: nemanjai, jvesely, nhaehnle, javed.absar, kbarton, emaste, arichardson, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58892 llvm-svn: 356226
2019-03-15 09:29:57 +08:00
// CHECK-NEXT: Address: 0x178
Fix handling of addends on i386. Because of merge sections it is not sufficient to just add them while applying a relocation. llvm-svn: 264863
2016-03-30 20:40:38 +08:00
// CHECK-NEXT: Offset:
// CHECK-NEXT: Size:
// CHECK-NEXT: Link:
// CHECK-NEXT: Info:
// CHECK-NEXT: AddressAlignment:
// CHECK-NEXT: EntrySize:
// CHECK-NEXT: SectionData (
// CHECK-NEXT: 0000: 42000000 |
// CHECK-NEXT: )
Don't depend on dynamic relocatinos in ro sections. Currently we don't check when creating relative relocations if the section is read only or not. I am about to fix that, so first update the patches that depend on the current behavior. llvm-svn: 268542
2016-05-05 04:25:19 +08:00
// CHECK: Name: .data
Fix handling of addends on i386. Because of merge sections it is not sufficient to just add them while applying a relocation. llvm-svn: 264863
2016-03-30 20:40:38 +08:00
// CHECK-NEXT: Type: SHT_PROGBITS
// CHECK-NEXT: Flags [
// CHECK-NEXT: SHF_ALLOC
Don't depend on dynamic relocatinos in ro sections. Currently we don't check when creating relative relocations if the section is read only or not. I am about to fix that, so first update the patches that depend on the current behavior. llvm-svn: 268542
2016-05-05 04:25:19 +08:00
// CHECK-NEXT: SHF_WRITE
Fix handling of addends on i386. Because of merge sections it is not sufficient to just add them while applying a relocation. llvm-svn: 264863
2016-03-30 20:40:38 +08:00
// CHECK-NEXT: ]
[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 11:47:45 +08:00
// CHECK-NEXT: Address: 0x2000
// CHECK-NEXT: Offset: 0x2000
Fix handling of addends on i386. Because of merge sections it is not sufficient to just add them while applying a relocation. llvm-svn: 264863
2016-03-30 20:40:38 +08:00
// CHECK-NEXT: Size: 4
// CHECK-NEXT: Link: 0
// CHECK-NEXT: Info: 0
Don't depend on dynamic relocatinos in ro sections. Currently we don't check when creating relative relocations if the section is read only or not. I am about to fix that, so first update the patches that depend on the current behavior. llvm-svn: 268542
2016-05-05 04:25:19 +08:00
// CHECK-NEXT: AddressAlignment: 1
Fix handling of addends on i386. Because of merge sections it is not sufficient to just add them while applying a relocation. llvm-svn: 264863
2016-03-30 20:40:38 +08:00
// CHECK-NEXT: EntrySize: 0
// CHECK-NEXT: SectionData (
[ELF] Split RW PT_LOAD on the PT_GNU_RELRO boundary Summary: Based on Peter Collingbourne's suggestion in D56828. Before D56828: PT_LOAD(.data PT_GNU_RELRO(.data.rel.ro .bss.rel.ro) .bss) Old: PT_LOAD(PT_GNU_RELRO(.data.rel.ro .bss.rel.ro) .data .bss) New: PT_LOAD(PT_GNU_RELRO(.data.rel.ro .bss.rel.ro)) PT_LOAD(.data. .bss) The new layout reflects the runtime memory mappings. By having two PT_LOAD segments, we can utilize the NOBITS part of the first PT_LOAD and save bytes for .bss.rel.ro. .bss.rel.ro is currently small and only used by copy relocations of symbols in read-only segments, but it can be used for other purposes in the future, e.g. if a relro section's statically relocated data is all zeros, we can move it to .bss.rel.ro. Reviewers: espindola, ruiu, pcc Reviewed By: ruiu Subscribers: nemanjai, jvesely, nhaehnle, javed.absar, kbarton, emaste, arichardson, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58892 llvm-svn: 356226
2019-03-15 09:29:57 +08:00
// CHECK-NEXT: 0000: 78010000 |
Fix handling of addends on i386. Because of merge sections it is not sufficient to just add them while applying a relocation. llvm-svn: 264863
2016-03-30 20:40:38 +08:00
// CHECK-NEXT: )
[ELF] Make non-writable non-executable PROGBITS sections closer to .text This generalizes the old heuristic placing SHT_DYNSYM SHT_DYNSTR first in the readonly SHF_ALLOC segment. Reviewers: espindola Subscribers: emaste, arichardson, llvm-commits Differential Revision: https://reviews.llvm.org/D48406 llvm-svn: 335674
2018-06-27 06:13:32 +08:00
// The content of .data should be the address of .mysec.
Fix handling of addends on i386. Because of merge sections it is not sufficient to just add them while applying a relocation. llvm-svn: 264863
2016-03-30 20:40:38 +08:00
Don't depend on dynamic relocatinos in ro sections. Currently we don't check when creating relative relocations if the section is read only or not. I am about to fix that, so first update the patches that depend on the current behavior. llvm-svn: 268542
2016-05-05 04:25:19 +08:00
.data
Fix handling of addends on i386. Because of merge sections it is not sufficient to just add them while applying a relocation. llvm-svn: 264863
2016-03-30 20:40:38 +08:00
.long .mysec+4
.section .mysec,"aM",@progbits,4
.align 4
.long 0x42
.long 0x42