Intention of change is to get rid of code duplication.
Decompressor was introduced in D28105.

Change allows to get rid of few methods relative to decompression.

Differential revision: https://reviews.llvm.org/D28106

llvm-svn: 291758

Previously, files added using INCLUDE directive weren't added
to reproduce archives. In this patch, I defined a function to
open a file and use that from Driver and LinkerScript.

llvm-svn: 291413

llvm-svn: 291223

This is how we use TarWriter in LLD. Now LLD does not append
a file extension, so you need to pass `--reproduce foo.tar`
instead of `--reproduce foo`.

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

llvm-svn: 291210

We managed new MemoryBuffers in different ways in LinkerScript.cpp and
Driver.cpp. With this patch, they are managed in the same way.

llvm-svn: 290411

Relocatable file does not need to have an entry symbol so the warning is
useless in that case.

llvm-svn: 290206

This value is used only once, and we can compute a value.
So we don't need to save it.

llvm-svn: 290164

Previously, some errors that were checked before we set to
Config->ColorDiagnostics weren't colored. This patch moves the code
to set the variable so that such error messages are colored just like
other error messages.

llvm-svn: 290157

That variable was of type DenseMap<StringRef, unsigned>, but the
unsigned numbers needed to be monotonicly increasing numbers because
the implementation that used the variable depended on that fact.
That was an implementation detail and shouldn't have leaked into Config.

This patch simplifies its type to std::vector<StringRef>.

llvm-svn: 290151

llvm-svn: 290150

--retain-symbols-file=filename
Retain only the symbols listed in the file filename, discarding all others. 
filename is simply a flat file, with one symbol name per line. This option 
is especially useful in environments (such as VxWorks) where a large global 
symbol table is accumulated gradually, to conserve run-time memory.

Note: though documentation says "--retain-symbols-file does not discard 
undefined symbols, or symbols needed for relocations.", both bfd and gold 
do that, and this patch too, like testcase show.

Differential revision: https://reviews.llvm.org/D27716

llvm-svn: 290122

Use of CachedHashStringRef makes sense only when we reuse hash values.
Sprinkling it to all DenseMap has no benefits and just complicates data types.
Basically we shouldn't use CachedHashStringRef unless there is a strong
reason to to do so.

llvm-svn: 290076

I thought for a while about how to remove it, but it looks like we
can just copy the file for now. Of course I'm not happy about that,
but it's just less than 50 lines of code, and we already have
duplicate code in Error.h and some other places. I want to solve
them all at once later.

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

llvm-svn: 290062

llvm-svn: 289146

llvm-svn: 289084

The feature is documented as
-----------------------------
The format of the dynamic list is the same as the version node
without scope and node name.  See *note VERSION:: for more
information.
--------------------------------

And indeed qt uses a dynamic list with an 'extern "C++"' in it. With
this patch we support that

The change to gc-sections-shared makes us match bfd. Just because we
kept bar doesn't mean it has to be in the dynamic symbol table.

The changes to invalid-dynamic-list.test and reproduce.s are because
of the new parser.

The changes to version-script.s are the only case where we change
behavior with regards to bfd, but I would like to see a mix of
--version-script and --dynamic-list used in the wild before
complicating the code.

llvm-svn: 289082

llvm-svn: 289081

llvm-svn: 289079

llvm-svn: 289078

This is the last peculiar semantics left in the linker. If you want to
always set an entry point to 0, you can pass `-e 0` to the linker.

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

llvm-svn: 289077

Thanks to Rui for the suggestion.

llvm-svn: 288982

Now Target->MaxPageSize is only used as the default value of
Config->MaxPageSize.

llvm-svn: 288974

llvm-svn: 288885

Config->WarnMissingEntry is a single-purpose boolean variable, and
I think it's easier to understand than Config->HasEntry.

llvm-svn: 288883

This patch is to parse the entry symbol name lazily.

llvm-svn: 288882

Shared libraries should have entry set following the same rules as for
regular binaries. The only difference is that in case the default entry
point (_start or __start) isn't found (unless it was set explicitly), we
shouldn't give a warning as in case of regular binaries.

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

llvm-svn: 288878

They might be used by relocations.

Fixes pr31252.

llvm-svn: 288617

llvm-svn: 288599

--omagic is an option to create old-fashioned executables in which
.text segments are writable. Today, the option is still in use to
create special-purpose programs such as boot loaders. It doesn't
make sense to create PT_GNU_RELRO for such executables.

DIfferential revision: https://reviews.llvm.org/D27297

llvm-svn: 288579

llvm-svn: 288130

-N (-omagic)
  Set the text and data sections to be readable and writable. 
  Also, do not page-align the data segment.

Differential revision: https://reviews.llvm.org/D26888

llvm-svn: 288123

Previously Config->SingleRoRx was set in
createFiles() and used HasSections.

This change moves it to readConfigs at place of
common flags handling, and adds logic that sets
this flag separatelly from ScriptParser if SECTIONS present.

llvm-svn: 288021

--no-rosegment: Do not put read-only non-executable sections in their own segment

Differential revision: https://reviews.llvm.org/D26889

llvm-svn: 288020

Config->ColorDiagnostics was of type enum before. Now it is just a
boolean flag. Thanks Rafael for suggestion.

llvm-svn: 287978

llvm-svn: 287967

-color-diagnostics=auto is default because that's the same as
Clang's default. When color is enabled, error or warning messages
are colored like this.

  error:
  <bold>ld.lld</bold> <red>error:</red> foo.o: no such file

  warning:
  <bold>ld.lld</bold> <magenta>warning:</magenta> foo.o: no such file

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

llvm-svn: 287949

llvm-svn: 287948

Uncompressing section contents and spliting mergeable section contents
into smaller chunks are heavy tasks. They scan entire section contents
and do CPU-intensive tasks such as uncompressing zlib-compressed data
or computing a hash value for each section piece.

Luckily, these tasks are independent to each other, so we can do that
in parallel_for_each. The number of input sections is large (as opposed
to the number of output sections), so there's a large parallelism here.

Actually the current design to call uncompress() and splitIntoPieces()
in batch was chosen with doing this in mind. Basically what we need to
do here is to replace `for` with `parallel_for_each`.

It seems this patch improves latency significantly if linked programs
contain debug info (which in turn contain lots of mergeable strings.)
For example, the latency to link Clang (debug build) improved by 20% on
my machine as shown below. Note that ld.gold took 19.2 seconds to do
the same thing.

Before:
    30801.782712 task-clock (msec)         #    3.652 CPUs utilized            ( +-  2.59% )
         104,084 context-switches          #    0.003 M/sec                    ( +-  1.02% )
           5,063 cpu-migrations            #    0.164 K/sec                    ( +- 13.66% )
       2,528,130 page-faults               #    0.082 M/sec                    ( +-  0.47% )
  85,317,809,130 cycles                    #    2.770 GHz                      ( +-  2.62% )
  67,352,463,373 stalled-cycles-frontend   #   78.94% frontend cycles idle     ( +-  3.06% )
 <not supported> stalled-cycles-backend
  44,295,945,493 instructions              #    0.52  insns per cycle
                                           #    1.52  stalled cycles per insn  ( +-  0.44% )
   8,572,384,877 branches                  #  278.308 M/sec                    ( +-  0.66% )
     141,806,726 branch-misses             #    1.65% of all branches          ( +-  0.13% )

     8.433424003 seconds time elapsed                                          ( +-  1.20% )

After:
    35523.764575 task-clock (msec)         #    5.265 CPUs utilized            ( +-  2.67% )
         159,107 context-switches          #    0.004 M/sec                    ( +-  0.48% )
           8,123 cpu-migrations            #    0.229 K/sec                    ( +- 23.34% )
       2,372,483 page-faults               #    0.067 M/sec                    ( +-  0.36% )
  98,395,342,152 cycles                    #    2.770 GHz                      ( +-  2.62% )
  79,294,670,125 stalled-cycles-frontend   #   80.59% frontend cycles idle     ( +-  3.03% )
 <not supported> stalled-cycles-backend
  46,274,151,813 instructions              #    0.47  insns per cycle
                                           #    1.71  stalled cycles per insn  ( +-  0.47% )
   8,987,621,670 branches                  #  253.003 M/sec                    ( +-  0.60% )
     148,900,624 branch-misses             #    1.66% of all branches          ( +-  0.27% )

     6.747548004 seconds time elapsed                                          ( +-  0.40% )

llvm-svn: 287946

HasError was always true if ErrorCount > 0, so we can use ErrorCount instead.

llvm-svn: 287849

This is in the context of https://llvm.org/bugs/show_bug.cgi?id=31109.
When LLD prints out errors for relocations, it tends to print out
extremely large number of errors (like millions) because it would
print out one error per relocation.

This patch makes LLD bail out if it prints out more than 20 errors.
You can configure the limitation using -error-limit argument.
-error-limit=0 means no limit.

I chose the flag name because Clang has the same feature as -ferror-limit.
"f" doesn't make sense to us, so I omitted it.

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

llvm-svn: 287789