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
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
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
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
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
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
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
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
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
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
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
Dmitry Mikulin