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

llvm-svn: 296508

llvm-svn: 296507

I do not fully understand why we had these values in the tests, but
the new value matches what ld.bfd and ld.gold set, so I guess that
was just a mistake.

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

llvm-svn: 296505

This reverts commit r296378.

I am pretty sure this is incorrect. In particular, for just

        .cfi_startproc
        nop
        .cfi_endproc

We now add an extra 4 zeros that neither bfd nor gold add.

llvm-svn: 296503

It does not make sense. Them added either to
Out::BssRelRo or Out::Bss, which are always RW.

llvm-svn: 296475

We do not use it later, so don't have to store.

llvm-svn: 296466

There are many special cases and a layer of abstraction or two in the
way, but the VA calculation in the typical case is actually very simple
and probably makes perfect sense even to somebody new to linkers.

Also, this line brings together many components and is a good place to
start understanding the linker (or improve one's existing
understanding).

llvm-svn: 296451

Naively it seemed at first like getVA had the responsibility of adding
the addend, and getSymVA had the responsibility of getting the symbol
VA.
So it was not obvious to me at first why getVA passes Addend to
getSymVA. In fact, it passes it as a mutable reference.

It turns out that it only matters for SHF_MERGE sections, and in
particular only for STT_SECTION symbols that are used as a hack for
reducing the number of local symbols (e.g. to avoid a local symbol for
each string in the string table).

llvm-svn: 296448

In other places in LLD, we use write32<E> instead of Elf_Word.
This patch uses the same technique in the hash table classes.
The hash table classes needs improving as they have almost no
comments. We at least need to describe the hash table structure
and why we have to support two different on-disk hash tables
for the same purpose. I'll do that later.

llvm-svn: 296439

llvm-svn: 296437

These assignments seem meaningful, but actually all tests pass without them.

llvm-svn: 296436

Previously, these two functions put their symbols in different queues.
Now that the queues have been merged. So there's no point to keep two
separate functions.

llvm-svn: 296435

llvm-svn: 296434

That function doesn't use any member of SymbolTableSection, so I
couldn't see a reason to make it a member of that class. The function
takes a SymbolBody, so it is more natural to make it a member of
SymbolBody.

llvm-svn: 296433

Previously, there were three conditions: .symtab, .dynsym or we are
producing a relocatable output. Turned out that the third condition is
the same as the first one. This patch removes that third condition and
simplify code.

llvm-svn: 296431

We really need to find a way to get this info from a single point of
truth in the LLVM backend, but it seems that the EM_* constants are
buried deep inside the constructors of the MCAsmBackend's.

For now, just fill in entries as we run into cases. AFAIK these mappings
are largely immutable, so we get a 75% discount on the technical debt
(code is duplicated, but little chance of divergence).

llvm-svn: 296429

The previous code was a bit hard to understand because it unnecessarily
distinguished local and non-local symbols. It had NumLocals member
variable, but that variable didn't have a number of local symbols but
had some value that I cannot describe easily.

This patch rewrites SynbolTableSection::finalizeContents and
SymbolTableSection::writeTo to make it easy to understand. NumLocals
member variable has been removed, and writeGlobalSymbols and
writeLocalSymbols have been merged into one function.

There's still a piece of code that I think unnecessary. I'm not removing
that code in this patch, but will do in a follow-up patch.

llvm-svn: 296423

This part of code is hard to understand because NumLocals does not
actually mean the number of local symbols but something else (!).
We need to rewrite. But before that we need to clean it up.

llvm-svn: 296400

Patch by Mark Kettenis.

Currenlty ld.lld does not add a terminator (a CIE with its length field
set to zero) to the .eh_frame sections it generates.  While the relevant
standards (the AMD64 SysV ABI and the Linux LSB) are not explicit about
this, such a terminator is expected by some unwinder implementations and
seems to be always emitted by ld.bfd. In addition to that, the Linux LSB

  https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/ehframechpt.html#EHFRAME

explicitly says that

  The .eh_frame section shall contain 1 or more Call Frame Information
  (CFI) records.

Currently, if the .eh_frame sections of the input files only contain
terminators, ld.lld emits a zero=sized .eh_frame section
which clearly doesn't meet that requirement.

The diff makes sure a terminator gets added to each .eh_frame section
and adjusts all the relevant tests to account for that.  An additional
test isn't needed as these adjustments mean that the existence of the
terminator is tested for by several tests already.

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

llvm-svn: 296378

Pointed out by Bob Haarman.

llvm-svn: 296377

llvm-svn: 296319

llvm-svn: 296318

llvm-svn: 296316

llvm-svn: 296315

In LLD source code, too many functions are called "finalize", although
what they do are different. This patch gives it a better name.

llvm-svn: 296314

This class didn't use ELFT.

llvm-svn: 296313

llvm-svn: 296311

llvm-svn: 296310

The list of all input sections was defined in SymbolTable class for a
historical reason. The list itself is not a template. However, because
SymbolTable class is a template, we needed to pass around ELFT to access
the list. This patch moves the list out of the class so that it doesn't
need ELFT.

llvm-svn: 296309

Since OutputSection is no longer a template, it doesn't make much
sense to tempalte its factory class.

llvm-svn: 296308

llvm-svn: 296307

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

llvm-svn: 296303

llvm-svn: 296232

llvm-svn: 296230

Now a function to parse -foo-bar is always named getFooBar.

llvm-svn: 296229

llvm-svn: 296227

llvm-svn: 296226

llvm-svn: 296225

llvm-svn: 296224

llvm-svn: 296223