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

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

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

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

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

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

llvm-svn: 293100

llvm-svn: 293095

It now uses the same infrastructure as symbol versions. This fixes us
creating a dynamic relocation without a corresponding dynamic symbol.

This also means that unlike gold and bfd we keep a STB_LOCAL in the
static symbol table. It seems an odd feature to offer precise control
over what is in a symbol table that is not used by the dynamic
linker. We can bring this back if needed, but it would probably be
better to just have --discard option that tells the linker to keep in
the static symbol table only what is in the dynamic one.

Should fix the eog build.

llvm-svn: 293093

llvm-svn: 293089

These relocations are used in linux kernel.

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

llvm-svn: 293054

    
Mapping symbols allow a mapping symbol aware disassembler to
correctly disassemble the PLT when the code immediately prior to the
PLT is Thumb.

To implement this we add a function to add symbols with local
binding to be defined in SyntheticSymbols.

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

llvm-svn: 293044

llvm-svn: 292980

Next code crashed under MSVS2015 for me:
this->OutSec->Info = this->Info = 1 + It - Symbols.begin();

Because It was end() and addition of 1 is not allowed. 
vector implementation catched and failed that inside:

_Myiter& operator+=(difference_type _Off)
{	// increment by integer
 #if _ITERATOR_DEBUG_LEVEL == 2
if (this->_Getcont() == 0
	|| this->_Ptr + _Off < ((_Myvec *)this->_Getcont())->_Myfirst
	|| ((_Myvec *)this->_Getcont())->_Mylast < this->_Ptr + _Off)
   {	// report error
	_DEBUG_ERROR("vector iterator + offset out of range");
	_SCL_SECURE_OUT_OF_RANGE;

llvm-svn: 292940

    
The sh_info field of the SHT_SYMTAB section holds the index for the
first non-local symbol. When there are global symbols that are output
with STB_LOCAL binding due to having hidden visibility or matching
the local version from a version script, the calculated value of
NumLocals + 1 does not account for them. This change accounts for
global symbols being output with local binding.

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

llvm-svn: 292910

It was requested during post commit review.

llvm-svn: 292903

Currently ld.lld -r allocates space for common symbols, whereas ld.bfd
-r doesn't.  As a result the OpenBSD makefile bits for creating libraries
fail as they use ld -X -r to strip local symbols, which results in
duplicate symbol errors because space for the common symbols has been
allocated.

The diff also implements the --define-commons option such that allocation
of commons can be forced even if -r is used.

Patch by Mark Kettenis.

llvm-svn: 292878