Thunks are now implemented by redirecting the relocation to the
symbol S, to a symbol TS in a Thunk. The Thunk will transfer control
to S. This has the following implications:
- All the side-effects of Thunks happen within createThunks()
- Thunks are no longer stored in InputSections and Symbols no longer
  need to hold a pointer to a Thunk
- The synthetic Thunk sections need to be merged into OutputSections
    
This implementation is almost a direct conversion of the existing
Thunks with the following exceptions:
- Mips LA25 Thunks are placed before the InputSection that defines
  the symbol that needs a Thunk.
- All ARM Thunks are placed at the end of the OutputSection of the
  first caller to the Thunk.
    
Range extension Thunks are not supported yet so it is optimistically
assumed that all Thunks can be reused.

This is a recommit of r293283 with a fixed comparison predicate as
std::merge requires a strict weak ordering.

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

llvm-svn: 293757

llvm-svn: 293751

Accidentally lost the commit title and message,
will recommit.

llvm-svn: 293750

llvm-svn: 293749

This is alternative to D28857 which was incorrect.

One of linux scripts contains:

vvar_start = . - 2 * (1 << 12);
vvar_page = vvar_start;
vvar_vsyscall_gtod_data = vvar_page + 128;
Previously we did not mark first expression as non-absolute,
though it contains location counter.

And LLD failed with error:
relocation R_X86_64_PC32 cannot refer to absolute symbol

This patch should fix the issue, and opens road for doing the same for other operators
(though not clear if that is needed).

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

llvm-svn: 293748

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

It is not clear what we should do when overflow occurs for these
relocations because the relocations are not an official part of
the i386 psABI. But checking for overflow is generally a good to do
and is consistent with other relocations such as R_X86_64_8.

llvm-svn: 293683

Our reporting for that case was just like:
ld.lld: error: do not know how to handle relocation 'R_386_PC8' (23)
It did not give any information about error location.

Patch adds filename to error.

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

llvm-svn: 293640

Add the CMake bits necessary to run lld tests (and unittests) when
building stand-alone. The code is based on the equivalent code in clang,
and includes:

1. checking for Python, searching for lit and necessary LLVM test tools
(FileCount and not),

2. building LLVM test tools (FileCount and not) from LLVM sources if
they are not installed,

3. building gtest libraries from LLVM sources,

4. adjusting dependencies so that test targets depend only on those LLVM
targets that are available for a particular variant of stand-alone
build.

With this patch, I am able to successfully run 1002 (+10 unsupported)
lit tests on Gentoo using installed LLVM.

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

llvm-svn: 293630

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

llvm-svn: 293613

Linux kernel linkerscript contains additional semicolon (last line):

.apicdrivers : AT(ADDR(.apicdrivers) - LOAD_OFFSET) {
  __apicdrivers = .;
  *(.apicdrivers);

I checked that both gold and bfd are able to parse something like:

.text : { ;;*(.text);;S = 0;; } }

Patch do the same.

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

llvm-svn: 293612

It currently depends on the fact that we don't concatenate merge
sections with the same name but different properties.

llvm-svn: 293583

llvm-svn: 293529

If no bss sections appear after the relro segment, the loader will round
the r/w segment size to the target's page size. Align the relro size in the
same way to ensure that it does not extend past the end of the program's
own memory region.

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

llvm-svn: 293519

ld.bfd showed error on previous inputs, result values were larger than 8/16 bits,
though ld.gold accepted them.

ABI says "The R_386_16, and R_386_8 relocations truncate the computed 
value to 16-bits and 8-bits respectively".

Patch changes inputs to have result calculated values of relocations to fit 8 and 16 bits.
That can be used for implementation of more strict checks, like bfd do.

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

llvm-svn: 293479

llvm-svn: 293452

llvm-svn: 293409

llvm-svn: 293390

The symbols _end, end, _etext, etext, _edata, edata and __ehdr_start
refer to positions in the file and are therefore not absolute. Making
them absolute was on unfortunate cargo cult of what bfd was doing.

Changing the symbols allows for pc relocations to them to be resolved,
which should fix the wine build.

llvm-svn: 293385

llvm-svn: 293380

This reverts commit r293283 because it broke MSVC build.

llvm-svn: 293352

    [ELF] Fixed formatting. NFC

and

    [ELF] Bypass section type check

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

They do the opposite of what was asked for in the code review.

llvm-svn: 293320

Now reportUndefined only has to look at Config->UnresolvedSymbols and
the symbol. getUnresolvedSymbolOption does all the hard work of
mapping options like -shared and -z defs to one of the
UnresolvedPolicy enum entries.

The critical fix is that now "-z defs --warn-unresolved-symbols" only
warns.

llvm-svn: 293290

    
Thunks are now implemented by redirecting the relocation to the
symbol S, to a symbol TS in a Thunk. The Thunk will transfer control
to S. This has the following implications:
- All the side-effects of Thunks happen within createThunks()
- Thunks are no longer stored in InputSections and Symbols no longer
  need to hold a pointer to a Thunk
- The synthetic Thunk sections need to be merged into OutputSections
    
This implementation is almost a direct conversion of the existing
Thunks with the following exceptions:
- Mips LA25 Thunks are placed before the InputSection that defines
  the symbol that needs a Thunk.
- All ARM Thunks are placed at the end of the OutputSection of the
  first caller to the Thunk.
    
Range extension Thunks are not supported yet so it is optimistically
assumed that all Thunks can be reused.

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

llvm-svn: 293283

llvm-svn: 293278

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

llvm-svn: 293276

Currently LLVM can only generate PIC code for MIPS64 with the N64 as
it uses the idiom "isPositionIndependent() || IsABI_N64()" throughout the
MIPS backend. r293164 changed this, causing test failures for LLD.

This patch changes the tests minimally to preserve existing test coverage
and one case where the test was "right" in the wrong circumstance.

Reviewers: atanasyan

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

llvm-svn: 293275

Should fix a few freebsd packages with dtrace.

llvm-svn: 293177

llvm-svn: 293144

Negative flags are still bit flags, so I think "not flag" is a very good name.

llvm-svn: 293143

llvm-svn: 293142

llvm-svn: 293141

Patch by Dmitry Mikulin.
PR: 31735

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

llvm-svn: 293139

Now we never append a number to the file name for task ID 0.

This is similar to r293132 in the gold plugin.

llvm-svn: 293138

llvm-svn: 293130

Summary: MSVC allows linker options to be specified in source code. One of these is the /INCLUDE directive, which specifies that a symbol must be added to the symbol table, even if it otherwise wouldn't be. Existing tests cover the case where the linker is given an object file with an /INCLUDE directive, but we also need to cover the case where /INCLUDE is specified in a bitcode file (as would happen when using LTO). This new test covers that case.

Reviewers: pcc, ruiu

Reviewed By: ruiu

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

llvm-svn: 293107

This eliminates one overload on the term Raw.

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

llvm-svn: 293104

llvm-svn: 293100

llvm-svn: 293096

llvm-svn: 293095