Thanks to Andrew Ng for noticing it.

llvm-svn: 303354

When /DEBUG is not specified, /PDB should be ignored.  When
/DEBUG is specified, a PDB should be output regardless of
whether or not /PDB is specified.  /PDB just overrides the
default name.

This patch implements this behavior, and adds some tests, while
also removing a dead option /DEBUGPDB which was unused in any
code.

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

llvm-svn: 303352

This change adds support for the R_ARM_SBREL32 relocation. The relocation
is a base relative relocation that is produced by clang/llvm when -frwpi
is used. The use case for the -frwpi option is position independent data
for embedded systems that do not have a GOT. With -frwpi all data is
accessed via an offset from a base register (usually r9), where r9 is set
at run time to where the data has been loaded. The base of the data is
known as the static base.

The ARM ABI defines the static base as:
B(S) is the addressing origin of the output segment defining the symbol S.
The origin is not required to be the base address of the segment. For
simplicity we choose to use the base address of the segment.

The ARM procedure call standard only defines a read write variant using
R_ARM_SBREL32 relocations. The read-only data is accessed via pc-relative
offsets from the code, this is implemented in clang as -fropi.

Fixes PR32924

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

llvm-svn: 303337

This reverts re-submits r303225 which was reverted in r303270 because it
broke the sanitizer-windows bot.

The reason of the failure is that we were writing dead symbols to the
symbol table. I fixed the issue.

llvm-svn: 303304

and follow-up r303226 "Fix Windows buildbots."

This broke the sanitizer-windows buildbot.

> Previously, the garbage collector (enabled by default or by explicitly
> passing /opt:ref) did not kill dllimported symbols. As a result,
> dllimported symbols could be added to resulting executables' dllimport
> list even if no one was actually using them.
>
> This patch implements dllexported symbol garbage collection. Just like
> COMDAT sections, dllimported symbols now have Live bits to manage their
> liveness, and MarkLive marks reachable dllimported symbols.
>
> Fixes https://bugs.llvm.org/show_bug.cgi?id=32950
>
> Reviewers: pcc
>
> Subscribers: llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D33264

llvm-svn: 303270

Nothing special here, just detemplates code that became possible 
to detemplate after recent commits in a straghtforward way.

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

llvm-svn: 303237

llvm-svn: 303226

Summary:
Previously, the garbage collector (enabled by default or by explicitly
passing /opt:ref) did not kill dllimported symbols. As a result,
dllimported symbols could be added to resulting executables' dllimport
list even if no one was actually using them.

This patch implements dllexported symbol garbage collection. Just like
COMDAT sections, dllimported symbols now have Live bits to manage their
liveness, and MarkLive marks reachable dllimported symbols.

Fixes https://bugs.llvm.org/show_bug.cgi?id=32950

Reviewers: pcc

Subscribers: llvm-commits

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

llvm-svn: 303225

llvm-svn: 303164

llvm-svn: 303155

Follow up for r303150.

llvm-svn: 303153

SymbolTableBaseSection was introduced.

Detemplation of SymbolTableSection should allow to detemplate more things.

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

llvm-svn: 303150

Switch to llvm::to_integer() everywhere in LLD instead of 
StringRef::getAsInteger() because API of latter is confusing. 
It returns true on error and false otherwise what makes reading 
the code incomfortable.

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

llvm-svn: 303149

llvm-svn: 303135

They are too slow otherwise. We track the issue in pr32942.

llvm-svn: 303097

We should only ever expect this function to return a regular
InputSection; I would not expect a function definition to be in a
MergeInputSection or EhInputSection. We were previously crashing
in writeTo if this function returned a section that was not an
InputSection because we do not set OutSec for such sections.

This can happen in practice if a function is defined in an empty
section which shares its offset-in-file with a MergeInputSection,
as in the provided test case.

A better fix for this bug would be to fix the
DWARFUnit::collectAddressRanges() interface to provide section
information (see D33183), but this at least fixes the crash.

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

llvm-svn: 303089

Fixes PR33032.

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

llvm-svn: 303088

This reorganisation prevents us from cluttering up the top-level lib directory
with more driver libraries such as llvm-dlltool (see D29892).

llvm-svn: 302995

llvm-svn: 302921

We used to place orphans by just using compareSectionsNonScript.

Then we noticed that since linker scripts can use another order, we
should first try match the section to a given PT_LOAD. But there is
nothing special about PT_LOAD. The same issue can show up for
PT_GNU_RELRO for example.

In general, we have to search for the most similar section and put the
orphan next to it. Most similar being defined as how long they follow
the same code path in compareSecitonsNonScript.

That is what this patch does. We now compute a rank for each output
section, with a bit for each branch in what was
compareSectionsNonScript.

With this findOrphanPos is now fully general and orphan placement can
be optimized by placing every section with the same rank at once.

The included testcase is a variation of many-sections.s that uses
allocatable sections to avoid the fast path in the existing
code. Without threads it goes form 46 seconds to 0.9 seconds.

llvm-svn: 302903

This reverts changes introduced in r302414 "[ELF] - Set DF_STATIC_TLS flag for i386 target."

Because DF_STATIC_TLS does not look to be used by glibc or anything else.

llvm-svn: 302884

Both gold and bfd restrict that one:

ld.bfd: test.o: relocation R_X86_64_TPOFF32 against `var' can not be 
used when making a shared object; recompile with -fPIC
ld.gold: error: test.o: unsupported reloc 23 against global symbol var

What looks reasonable because it is 32 bit one. Patch do the same.

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

llvm-svn: 302881

llvm-svn: 302849

llvm-svn: 302848

llvm-svn: 302847

llvm-svn: 302846

This is a bit hackish, but allows for a lot of followup cleanups.

llvm-svn: 302845

llvm-svn: 302843

llvm-svn: 302832

llvm-svn: 302828

llvm-svn: 302826

Testcase itself depends on .text section location, which was orphan earlier.

Suggested by Rafael Espíndola

llvm-svn: 302792

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

llvm-svn: 302748

llvm-svn: 302719

So that it is clear that the function is a wrapper for for_each_n.

llvm-svn: 302718

This improves many-sections.s with a linker script from 22s to 0.9s.

llvm-svn: 302708

We now always use getCmd. I will optimize it in a followup commit.

llvm-svn: 302706

llvm-svn: 302697

Previously we were not printing out the type of the incompatible section
which made it difficult to determine what the problem was.

The error message format has been change to the following:

  error: section type mismatch for .shstrtab
  >>> <internal>:(.shstrtab): SHT_STRTAB
  >>> output section .shstrtab: Unknown

Patch by Alexander Richardson.

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

llvm-svn: 302694

llvm-svn: 302690