|
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1 |
|
| #
b159906a |
| 01-May-2019 |
Fangrui Song <maskray@google.com> |
[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
[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
show more ...
|
|
Revision tags: llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1, llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1, llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1 |
|
| #
b6772b86 |
| 26-Jun-2018 |
Fangrui Song <maskray@google.com> |
[ELF] Move `// REQUIRES:` line to the top
llvm-svn: 335676
|
|
Revision tags: llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2, llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1, llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2, llvmorg-5.0.1-rc1, llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2, llvmorg-5.0.0-rc1, llvmorg-4.0.1, llvmorg-4.0.1-rc3, llvmorg-4.0.1-rc2, llvmorg-4.0.1-rc1, llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3, llvmorg-4.0.0-rc2, llvmorg-4.0.0-rc1 |
|
| #
33713983 |
| 05-Jan-2017 |
Rafael Espindola <rafael.espindola@gmail.com> |
Change which input sections we concatenate
After Mark's patch I was wondering what was the rationale for the ELF spec requiring us to merge only sections with matching flags and types. I tried email
Change which input sections we concatenate
After Mark's patch I was wondering what was the rationale for the ELF spec requiring us to merge only sections with matching flags and types. I tried emailing https://groups.google.com/forum/#!forum/generic-abi, but looks like my emails are not being posted (the list is probably moderated). I emailed Cary Coutant instead.
Cary pointed out that the section was a late addition and didn't got the scrutiny it deserved. Given that and the problems found by implementing the letter of the standard, I propose changing lld to merge all sections with the same name and issue errors if the types or some critical flags are different.
This should allow an unmodified firefox linked with lld to run.
This also merges some code with the linkerscript path.
llvm-svn: 291107
show more ...
|
| #
64cc2a0f |
| 04-Jan-2017 |
Rafael Espindola <rafael.espindola@gmail.com> |
Delete stale test.
We no longer tail merge section names.
llvm-svn: 290988
|
|
Revision tags: llvmorg-3.9.1, llvmorg-3.9.1-rc3, llvmorg-3.9.1-rc2, llvmorg-3.9.1-rc1 |
|
| #
8fd0196c |
| 23-Nov-2016 |
Ed Maste <emaste@freebsd.org> |
lld: Default image base address to 0x200000 on x86-64
Align to the large page size (known as a superpage or huge page). FreeBSD automatically promotes large, superpage-aligned allocations.
Differen
lld: Default image base address to 0x200000 on x86-64
Align to the large page size (known as a superpage or huge page). FreeBSD automatically promotes large, superpage-aligned allocations.
Differential Revision: https://reviews.llvm.org/D27042
llvm-svn: 287782
show more ...
|
| #
3da3f06d |
| 10-Nov-2016 |
Rui Ueyama <ruiu@google.com> |
Include version string into ".comment" section.
Summary: This patch adds a ".comment" section to an output. The comment section contains the linker's version string. You can now find out whether a b
Include version string into ".comment" section.
Summary: This patch adds a ".comment" section to an output. The comment section contains the linker's version string. You can now find out whether a binary is created by LLD or not using objdump command like this.
$ objdump -s -j .comment foo
foo: file format elf64-x86-64
Contents of section .comment: 0000 00474343 3a202855 62756e74 7520342e .GCC: (Ubuntu 4. 0010 382e342d 32756275 6e747531 7e31342e 8.4-2ubuntu1~14. ... 00c0 766d2f74 72756e6b 20323835 38343629 vm/trunk 285846) 00d0 004c696e 6b65723a 204c4c44 20342e30 .Linker: LLD 4.0 00e0 2e302028 7472756e 6b203238 36343036 .0 (trunk 286406 00f0 2900 ).
Compilers emits .comment section as well, so the output contains both compiler and linker information.
Alternative considered:
I first tried to add a SHT_NOTE section because GNU gold does that. A NOTE section starts with a header which contains content type. It turned out that ld.gold sets type NT_GNU_GOLD_VERSION to their NOTE section. So the NOTE type is only for GNU gold (surprise!)
Next, I tried to create ".linker-version" section. However, it seems that reusing the existing ".comment" section is better because 1) other tools already know about .comment section and is able to strip it and 2) the result contans not only linker info but also compiler info.
Differential Revision: https://reviews.llvm.org/D26487
llvm-svn: 286496
show more ...
|
|
Revision tags: llvmorg-3.9.0, llvmorg-3.9.0-rc3, llvmorg-3.9.0-rc2, llvmorg-3.9.0-rc1, llvmorg-3.8.1, llvmorg-3.8.1-rc1, llvmorg-3.8.0, llvmorg-3.8.0-rc3, llvmorg-3.8.0-rc2 |
|
| #
e2c2461a |
| 29-Jan-2016 |
Rafael Espindola <rafael.espindola@gmail.com> |
Merge identical strings.
This avoids the need to have reserve and addString in sync.
We avoid hashing the global symbols again. This means that we don't merge a global symbol that has the same name
Merge identical strings.
This avoids the need to have reserve and addString in sync.
We avoid hashing the global symbols again. This means that we don't merge a global symbol that has the same name as some other string, but that doesn't seem very common. The string table size is the same in clang an scylladb with or without hashing global symbols again.
llvm-svn: 259136
show more ...
|
|
Revision tags: llvmorg-3.8.0-rc1 |
|
| #
76c0063e |
| 07-Jan-2016 |
Rui Ueyama <ruiu@google.com> |
ELF: Improve performance of string table construction.
String tables in unstripped executable files are fairly large in size. For example, lld's executable file is about 34.4 MB in my environment, a
ELF: Improve performance of string table construction.
String tables in unstripped executable files are fairly large in size. For example, lld's executable file is about 34.4 MB in my environment, and of which 3.5 MB is the string table. Efficiency of string table construction matters.
Previously, the string table was built in an inefficient way. We used StringTableBuilder to build that and enabled string tail merging, although tail merging is not effective for the symbol table (you can only make the string table 0.3% smaller for lld.) Tail merging is computation intensive task and slow.
This patch eliminates string tail merging.
I changed the way of adding strings to the string table in this patch too. Previously, strings were added using add() and the same strings were then passed to getOffset() to get their offsets in the string table. In this way, getOffset() needs to look up a hash table to get offsets for given strings. This is a violation of "we look up the symbol table (or a hash table) only once for each symbol" dogma of the new LLD's design. Hash table lookup for long C++ mangled names is slow. I eliminated that lookup in this patch.
In total, this patch improves link time of lld itself about 12% (3.50 seconds -> 3.08 seconds.)
llvm-svn: 257017
show more ...
|
|
Revision tags: llvmorg-3.7.1 |
|
| #
7b19c345 |
| 24-Nov-2015 |
Rui Ueyama <ruiu@google.com> |
Revert "ELF: Make .note.GNU-stack more compatible with traditional linkers."
This reverts commit r253797 because it was based on a misunderstanding that lld wouldn't work on NetBSD without this chan
Revert "ELF: Make .note.GNU-stack more compatible with traditional linkers."
This reverts commit r253797 because it was based on a misunderstanding that lld wouldn't work on NetBSD without this change.
llvm-svn: 254003
show more ...
|
| #
e79b09a6 |
| 21-Nov-2015 |
Rui Ueyama <ruiu@google.com> |
ELF: Make .note.GNU-stack more compatible with traditional linkers.
With this patch, lld creates PT_GNU_STACK segments only when all input files have .note.GNU-stack sections. This is in line with o
ELF: Make .note.GNU-stack more compatible with traditional linkers.
With this patch, lld creates PT_GNU_STACK segments only when all input files have .note.GNU-stack sections. This is in line with other linkers with a minor difference (we don't care about .note.GNU-stack rwx bits as you can always remove .note.GNU-stack sections instead of setting x bit.)
At least, NetBSD loader does not understand PT_GNU_STACK segments and reject any executables that have the section. This patch makes lld compatible with such operating systems.
llvm-svn: 253797
show more ...
|
|
Revision tags: llvmorg-3.7.1-rc2 |
|
| #
9c8904fb |
| 18-Nov-2015 |
Rafael Espindola <rafael.espindola@gmail.com> |
Rename ld.lld2 to ld.lld since it is the default.
llvm-svn: 253437
|
| #
4b1285c5 |
| 17-Nov-2015 |
Rafael Espindola <rafael.espindola@gmail.com> |
Rename test/elf2 to test/ELF.
llvm-svn: 253313
|