summaryrefslogtreecommitdiffstats
path: root/lld/test/ELF/map-file.s
Commit message (Collapse)AuthorAgeFilesLines
* [ELF][X86] Allow PT_LOAD to have overlapping p_offset ranges on EM_X86_64Fangrui Song2019-09-161-38/+37
| | | | | | | | Port the D64906 technique to EM_X86_64. Differential Revision: https://reviews.llvm.org/D67482 llvm-svn: 371958
* [ELF] Split RW PT_LOAD on the PT_GNU_RELRO boundaryFangrui Song2019-03-151-16/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [ELF] Simplify RelRo, TLS, NOBITS section ranks and make RW PT_LOAD start ↵Fangrui Song2019-03-141-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [ELF] Make non-writable non-executable PROGBITS sections closer to .textFangrui Song2018-06-261-14/+14
| | | | | | | | | | | | 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
* [lld] Mitigate relocation overflow [part 1 of 2].Han Shen2018-05-151-14/+15
| | | | | | | | | | | This CL places .dynsym and .dynstr at the beginning of SHF_ALLOC sections. We do this to mitigate the possibility that huge .dynsym and .dynstr sections placed between ro-data and text sections cause relocation overflow. Differential Revision: https://reviews.llvm.org/D45788 llvm-svn: 332374
* [ELF] - Revert of: r332038, r332054, r332060, r332061, r332062, r332063George Rimar2018-05-111-15/+14
| | | | | | | | | | | This reverts "Mitigate relocation overflow [part 1 of 2]." and the following commits which were trying to fix the bots. At the moment of r332082, bots are still failing and we need to find the reason of test case breakages first of all. http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/17042/steps/test/logs/stdio http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/29845/steps/test/logs/stdio llvm-svn: 332085
* Mitigate relocation overflow [part 1 of 2].Han Shen2018-05-101-14/+15
| | | | | | | | | | | | This CL is to mitigate R_X86_64_PC32 relocation overflow problems for huge binaries that has near 4G allocated sections. By examining those binaries, there're 2 issues contributes to the problem: 1). huge ".dynsym" and ".dynstr" stands in the way between .rodata and .text 2). _init_array_start/end are placed at 0 if no ".init_array" presents, this causes .text relocation against them become more prone to overflow. This CL addresses 1st problem (the 2nd will be addressed in another CL.) by assigning a smaller sortrank to .dynsym and .dynstr thus they no longer stand in between. llvm-svn: 332038
* Add a CIE with length 0 unconditionally.Fangrui Song2018-05-081-1/+1
| | | | | | | | | | | | Summary: This is not technically required, but glibc unwind-dw2-fde.c classify_object_over_fdes expects there is a CIE record length 0 as a terminator. Reviewers: ruiu, espindola Subscribers: emaste, arichardson, llvm-commits Differential Revision: https://reviews.llvm.org/D46566 llvm-svn: 331708
* Replace SharedSymbols with Defined when creating copy relocations.Rafael Espindola2018-04-261-2/+2
| | | | | | | | | | | | | This is slightly simpler to read IMHO. Now if a symbol has a position in the file, it is Defined. The main motivation is that with this a SharedSymbol doesn't need a section, which reduces the size of SymbolUnion. With this the peak allocation when linking chromium goes from 568.1 to 564.2 MB. llvm-svn: 330966
* Make "Size" column in the map file one characters shorter.Rui Ueyama2018-04-051-54/+54
| | | | | | | | | Previously, "size" column is 9 characters long which is too long at least for 32-bit (because at maximum it needs 8 columns). This patch make it one column shorter than before. That's also a reasonable default for 64-bit. llvm-svn: 329317
* Fix column size in the map file.Rui Ueyama2018-04-051-54/+54
| | | | | | Size can be narrow, but LMA should be the same width as VMA. llvm-svn: 329312
* [ELF] - Print LMA in a -Map file.George Rimar2018-04-051-54/+54
| | | | | | | | | | Currently, LLD prints VA, but not LMA in a map file. It seems can be useful to print both to reveal layout details and patch implements it. Differential revision: https://reviews.llvm.org/D44899 llvm-svn: 329271
* Do not show alignment 0 because that is equivalent to 1.Rui Ueyama2018-04-041-16/+16
| | | | | | Differential Revision: https://reviews.llvm.org/D44991 llvm-svn: 329233
* [ELF] Add .eh_frame pieces to map fileRui Ueyama2018-03-141-3/+7
| | | | | | | | | This patch is a simplified version of https://reviews.llvm.org/D42960 written by Andrew Ng. Differential Revision: https://reviews.llvm.org/D44168 llvm-svn: 327574
* Don't depend on "call foo" producing a X86_64_PC32.Rafael Espindola2018-02-161-3/+6
| | | | | | | | | | Newer versions of the gnu assembler produce a X86_64_PLT32 for calls. There is a change under review in llvm to do the same, so update the tests to not depend on it. We can still produce a R_X86_64_PC32 with ".long foo - .". llvm-svn: 325379
* [ELF] - Show .plt symbols in -Map output.George Rimar2017-12-061-40/+50
| | | | | | | | | | As mentioned in PR35471, shared functions for which .plt entry address is used shows up in bfd's map files. Patch teaches LLD to do the same. Differential revision: https://reviews.llvm.org/D40839 llvm-svn: 319879
* Recommit r319747 "[ELF] - Show copy relocated symbols in a --Map file output."George Rimar2017-12-051-27/+47
| | | | | | | | | | | | | | | With fix: Specify -soname for input dso to fix up the .dynstr section size in different environments. Original commit message: As mentioned in PR35471, copied symbols did not show in --Map output. Patch fixes that. Differential revision: https://reviews.llvm.org/D40785 llvm-svn: 319769
* [ELF] - Revert r319747 "[ELF] - Show copy relocated symbols in a --Map file ↵George Rimar2017-12-051-47/+27
| | | | | | | | | | | | | | output.". It broke bots: http://lab.llvm.org:8011/builders/lld-x86_64-darwin13/builds/15570/steps/test_lld/logs/stdio http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/10930/steps/check-lld%20asan/logs/stdio http://lab.llvm.org:8011/builders/lld-x86_64-win7/builds/16336/steps/test%20lld/logs/stdio According to outputs, .dynstr section has different sizes for some reason. llvm-svn: 319749
* [ELF] - Show copy relocated symbols in a --Map file output.George Rimar2017-12-051-27/+47
| | | | | | | | | As mentioned in PR35471, copied symbols did not show in --Map output. Patch fixes that. Differential revision: https://reviews.llvm.org/D40785 llvm-svn: 319747
* Currently lld creates a single section to collect all commons. There is no wayDmitry Mikulin2017-09-081-1/+1
| | | | | | | | | | | | | | | to separate commons based on file name patterns. The following linker script construct does not work because commons are allocated before section placement is done and the only synthesized BssSection that holds all commons has no file associated with it: SECTIONS { .common_0 : { *file0.o(COMMON) }} This patch changes the allocation of commons to create a section per common symbol and let the section logic do the layout. Differential revision: https://reviews.llvm.org/D37489 llvm-svn: 312796
* Avoid crash with local abs symbol.Rafael Espindola2017-08-111-4/+7
| | | | llvm-svn: 310736
* [ELF] - Do not omit common symbols when -Map is given.George Rimar2017-08-111-0/+1
| | | | | | | | | | | This is PR33886, previously we did not output common symbols to map, patch fixes that. Differential revision: https://reviews.llvm.org/D36466 llvm-svn: 310703
* Change the format of the map file.Rui Ueyama2017-04-281-23/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, we printed out input sections and input files in separate columns as shown below. Address Size Align Out In File Symbol 0000000000201000 0000000000000015 4 .text 0000000000201000 000000000000000e 4 .text 0000000000201000 000000000000000e 4 foo.o 0000000000201000 0000000000000000 0 _start 0000000000201005 0000000000000000 0 f(int) 000000000020100e 0000000000000000 0 local 0000000000201010 0000000000000002 4 bar.o 0000000000201010 0000000000000000 0 foo 0000000000201011 0000000000000000 0 bar This format doesn't make much sense because for each input section, there's always exactly one input file. This patch changes the format to this. Address Size Align Out In Symbol 0000000000201000 0000000000000015 4 .text 0000000000201000 000000000000000e 4 foo.o:(.text) 0000000000201000 0000000000000000 0 _start 0000000000201005 0000000000000000 0 f(int) 000000000020100e 0000000000000000 0 local 0000000000201010 0000000000000002 4 bar.o:(.text) 0000000000201010 0000000000000000 0 foo 0000000000201011 0000000000000000 0 bar Differential Revision: https://reviews.llvm.org/D32657 llvm-svn: 301683
* Speed up the -Map option.Rui Ueyama2017-04-281-5/+5
| | | | | | | | | | | | | | | | | | | | | | We found that some part of code for the -Map option takes O(m*n) where m is the number of input sections in some file and n is the number of symbols in the same file. If you do LTO, we usually have only a few object files as inputs for the -Map option feature, so this performance characteristic was worse than I expected. This patch rewrites the -Map option feature to speed it up. I eliminated the O(m*n) bottleneck and also used multi-threading. As a result, clang link time with the -Map option improved from 18.7 seconds to 11.2 seconds. Without -Map, it takes 7.7 seconds, so the -Map option is now about 3x faster than before for this test case (from 11.0 seconds to 3.5 seconds.) The generated output file size was 223 MiB, and the file contains 1.2M lines. Differential Revision: https://reviews.llvm.org/D32631 llvm-svn: 301659
* [ELF] Fail the link early if the map file path is invalidJames Henderson2017-04-041-1/+1
| | | | | | | | | | | | | As with the changes made in r297645, we do not want a potentially long link to be run, if it will ultimately fail because the map file is not writable. This change reuses the same functionality as the output file path check. See https://reviews.llvm.org/D30449 for further justification and explanations. Reviewers: ruiu Differential Revision: https://reviews.llvm.org/D31603 llvm-svn: 299420
* Revert "Add terminator to .eh_frame sections"Rafael Espindola2017-02-281-2/+2
| | | | | | | | | | | | | | This reverts commit r296378. I am pretty sure this is incorrect. In particular, for just .cfi_startproc nop .cfi_endproc We now add an extra 4 zeros that neither bfd nor gold add. llvm-svn: 296503
* Add terminator to .eh_frame sectionsRui Ueyama2017-02-271-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch by Mark Kettenis. Currenlty ld.lld does not add a terminator (a CIE with its length field set to zero) to the .eh_frame sections it generates. While the relevant standards (the AMD64 SysV ABI and the Linux LSB) are not explicit about this, such a terminator is expected by some unwinder implementations and seems to be always emitted by ld.bfd. In addition to that, the Linux LSB https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/ehframechpt.html#EHFRAME explicitly says that The .eh_frame section shall contain 1 or more Call Frame Information (CFI) records. Currently, if the .eh_frame sections of the input files only contain terminators, ld.lld emits a zero=sized .eh_frame section which clearly doesn't meet that requirement. The diff makes sure a terminator gets added to each .eh_frame section and adjusts all the relevant tests to account for that. An additional test isn't needed as these adjustments mean that the existence of the terminator is tested for by several tests already. Differential Revision: https://reviews.llvm.org/D30335 llvm-svn: 296378
* Convert EhOutputSection to be a synthetic section.Rafael Espindola2017-02-231-0/+1
| | | | | | | | With this we complete the transition out of special output sections, and with the previous patches it should be possible to merge OutputSectionBase and OuputSection. llvm-svn: 296023
* Replace MergeOutputSection with a synthetic section.Rafael Espindola2017-02-031-0/+1
| | | | | | | | | | | | | | With a synthetic merge section we can have, for example, a single .rodata section with stings, fixed sized constants and non merge constants. I can be simplified further by not setting Entsize, but that is probably better done is a followup patch. This should allow some cleanup in the linker script code now that every output section command maps to just one output section. llvm-svn: 294005
* Print alignment in decimal instead of hexadecimal.Rui Ueyama2017-01-311-3/+3
| | | | | | | | | | | | | Previously, we were printing out something like this for sections/symbols with alignment 16 0000000000201000 0000000000000182 10 .data which I think confusing. I think printing it in decimal is better. Differential Revision: https://reviews.llvm.org/D29258 llvm-svn: 293685
* Return early if writeMapFile failed.Rui Ueyama2017-01-181-0/+4
| | | | | | | | This patch adds a test for an invalid output path for -Map option, though that test is not for verifying that we are using error() instead of fatal() in writeMapFile. llvm-svn: 292336
* Add -print-map and -M options.Rui Ueyama2017-01-151-1/+3
| | | | llvm-svn: 292046
* Try to fix the windows bots.Rafael Espindola2017-01-141-5/+5
| | | | llvm-svn: 291989
* Implement -Map.Rafael Espindola2017-01-131-0/+54
The format is not exactly the same as the one in bfd since bfd always follows a linker script and prints it along. llvm-svn: 291958
OpenPOWER on IntegriCloud