-z wxneeded creates a PHDR PT_OPENBSD_WXNEEDED.

PT_OPENBSD_WXNEEDED
The array element specifies that a process executing this file may need to be able to map or protect memory regions as simultaneously executable and writable. If the system is unable or unwilling to permit that for this executable then it may fail immediately. This segment type is meaningful only for executable files and is ignored in other objects.

http://man.openbsd.org/OpenBSD-current/man5/elf.5

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

llvm-svn: 284226

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

llvm-svn: 284197

llvm-svn: 284177

Previously we would fail to synthesise a __start_ or __stop_ symbol if
there existed a definition in a DSO. Instead, we would try to link against
the DSO definition. This became possible after D23552 when linking against
lld-produced DSOs but could in principle also occur when linking against
DSOs produced by other linkers.

Not only does it seem more likely that a user would expect the resolved
definition to be local to the executable, but if a __start_ or __stop_
symbol was synthesised by the linker, it is effectively impossible to link
against correctly from a non-PIC executable in a read-only section. Neither
a PLT nor a copy relocation would give us the right semantics here. The only
way the link could succeed is if the executable provided its own synthetic
definition of the symbol.

The fix is to also synthesise the definition if the only definition comes
from a DSO. Since this is what the addOptionalSynthetic function does,
switch to using that function.

Fixes PR30680.

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

llvm-svn: 284168

We've started using it in the ThinLTO tests.

Also remove a repeated dependency on llvm-nm.

llvm-svn: 284095

So that we can use the function from anywhere.

llvm-svn: 284092

llvm-svn: 284079

Previously, we supported only SHF_COMPRESSED sections because it's
new and it's the ELF standard. But there are object files compressed
in the GNU style out there, so we had to support it.

Sections compressed in the GNU style start with ".zdebug_" and
contain different headers than the ELF standard's one. In this
patch, getRawCompressedData is responsible to handle it.

A tricky thing about GNU-style compressed sections is that we have
to rename them when creating output sections. ".zdebug_" prefix
implies the section is compressed. We need to rename ".zdebug_"
".debug" because our output sections are not compressed.
We do that in this patch.

llvm-svn: 284068

llvm-svn: 284050

This fixes PR30665.

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

llvm-svn: 284034

r283984 introduced a problem of too many warning messages being shown
when -ffunction-sections and -fdata-sections were used in conjunction 
with --gc-sections linker flag and debugging information present. This
happens because lot of relocations from .debug_line section may become
invalid in such case. The newer fix doesn't show any warning message but
zeroes OutSec pointer in createInputSectionList() to avoid crash, when
relocations are written

llvm-svn: 284010

Following the lazy reference might bring in an object file that depends
on bitcode files that weren't part of the LTO step.

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

llvm-svn: 283989

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

llvm-svn: 283984

I don't really understand why we get a larger .rodata section only
on this bot. I guess it may be picking up a library which contains
a .rodata. I removed the specific values since their values are not
important for this test case.

llvm-svn: 283931

It was reverted because the change that depends on was reverted.
Now it was submitted as r283925, so we can submit this as well.

llvm-svn: 283926

llvm-svn: 283910

While here, fix the CHECK lines of an existing test.

llvm-svn: 283889

This part was splitted from D25016.

When sh_info value was set in the way that non-local symbol was treated as local, lld
was asserting, patch fixes that.

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

llvm-svn: 283859

The change this patch depends on was reverted.

llvm-svn: 283837

llvm-svn: 283826

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

llvm-svn: 283825

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

llvm-svn: 283817

Before the default was whatever number hardware_concurrency() returned.
Users can specify the number of threads via --lto-jobs=X option.

llvm-svn: 283787

llvm-svn: 283786

Sometimes the very first PT_LOAD segment, created by lld, can be empty. 
This happens when (all conditions met):

- Linker script is used
- First section in ELF image is not RO
- Not enough space for program headers.

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

llvm-svn: 283760

llvm-svn: 283742

Recommit r283733 "[ELF] - Do not crash if common symbol alignment set to value greater than UINT32_MAX.

With fix: commit changes from InputFiles.cpp too.

Original commit message:
We have following code in lld, that truncates the alignment value to 32 bit. Big alignment in this case
may give result 0 and crash later.

template <class ELFT>
CommonInputSection<ELFT>::CommonInputSection(std::vector<DefinedCommon *> Syms)
    : InputSection<ELFT>(nullptr, &Hdr, "") {
....
  for (DefinedCommon *Sym : Syms) {
    this->Alignment = std::max<uintX_t>(this->Alignment, Sym->Alignment);
...
  }
}

Patch fixes the issue.

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

llvm-svn: 283738

Revert r283733 "[ELF] - Do not crash if common symbol alignment set to value greater than UINT32_MAX."

Broke BB because forgot to commit source file.

llvm-svn: 283737

llvm-svn: 283735

.ARM.exidx sections have a reverse dependency on the section they have
a SHF_LINK_ORDER dependency on. In other words a .ARM.exidx section is
live only if the executable section it describes is live. We implement
this with a reverse dependency field in InputSection.

Adding the dependency to InputSection is the simplest implementation
but it could be moved out to a separate map if it were found to decrease
performance for non ARM targets.

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

llvm-svn: 283734

We have following code in lld, that truncates the alignment value to 32 bit. Big alignment in this case
may give result 0 and crash later.

template <class ELFT>
CommonInputSection<ELFT>::CommonInputSection(std::vector<DefinedCommon *> Syms)
    : InputSection<ELFT>(nullptr, &Hdr, "") {
....
  for (DefinedCommon *Sym : Syms) {
    this->Alignment = std::max<uintX_t>(this->Alignment, Sym->Alignment);
...
  }
}

Patch fixes the issue.

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

llvm-svn: 283733

Absolute local symbols with name staring from ".L" were reason of crash.
The same could happen when using some broken inputs found by AFL.

Patch fixes that.

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

llvm-svn: 283731

The .ARM.exidx sections contain a table. Each entry has two fields:
- PREL31 offset to the function the table entry describes
- Action to take, either cantunwind, inline unwind, or PREL31 offset to
  .ARM.extab section

The table entries must be sorted in order of the virtual addresses the
first entry of the table describes. Traditionally this is implemented by
the SHF_LINK_ORDER dependency. Instead of implementing this directly we
sort the table entries post relocation. 

The .ARM.exidx OutputSection is described by the PT_ARM_EXIDX program
header

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

llvm-svn: 283730

Also use uint64_t instead of uintX_t so that you don't have to
think about two different cases to verify that the code is correct.

llvm-svn: 283585

When sh_info of sumbol table value was set to zero, lld was asserting.

Patch fixes the issue.

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

llvm-svn: 283562

llvm-svn: 283556

I found that this check still may be useful in some cases.
At fact since we use uint32_t alignment, then maximum value
that is valid for us is 0x80000000. But some broken files,
for example file from testcase may have greater value.
Because of that offset calculation overflow and crash happens.

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

llvm-svn: 283544

Previously if sh_size of dynamic section was broken,
lld may crash. Or even may not crash if used 32 bits host.
(then value may be truncated to 32 bits when doing pointer arithmetic 
and could be just zero).
Patch fixes the issue.

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

llvm-svn: 283533

createELFObj() may call error(...), for example when file is too short.
In that case header is not set and following line lead to crash:

EMachine = ELFObj.getHeader()->e_machine;

Patch fixes the issue.

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

llvm-svn: 283532

llvm-svn: 283504