Summary: elf::fatal is declared "noreturn".

Reviewers: grimar

Subscribers: llvm-commits

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

llvm-svn: 291766

Previously we just crashed when had user defined
section .shstrtab, for example. Which name equals to synthetic one,
but have different type.

Testcase reveals an issue.

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

llvm-svn: 291765

Intention of change is to get rid of code duplication.
Decompressor was introduced in D28105.

Change allows to get rid of few methods relative to decompression.

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

llvm-svn: 291758

Addded quotes to be consistent with x64 messages,
where quotes were used for nicer reporting 'Unknown' relocations initially.

llvm-svn: 291752

The same we did for x86 earlier:
list supported relocations explicitly and error out on unknown.

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

llvm-svn: 291751

This patch is to merge type info in multiple .debug$T sections.

One mystery that needs to be solved is that it is not clear how
the MSVC linker uses TPI and IPI streams. Both streams contain
type info, and it is not obvious what kind of record should go
which.

dumppdb command in microsoft-pdb repository prints out IPI stream
contents as "IDs" and TPI stream as "TYPES", but looks like the tool
don't really care about which stream type recrods were read from.

For now, in this patch, I emit all type records to TPI stream.
It might just work with other tools. If not, we need to investigate
it more.

llvm-svn: 291739

Previously the type dumper itself was passed around to a lot of different
places and manipulated in ways that were more appropriate on the type
database. For example, the entire TypeDumper was passed into the symbol
dumper, when all the symbol dumper wanted to do was lookup the name of a
TypeIndex so it could print it. That's what the TypeDatabase is for --
mapping type indices to names.

Another example is how if the user runs llvm-pdbdump with the option to
dump symbols but not types, we still have to visit all types so that we
can print minimal information about the type of a symbol, but just without
dumping full symbol records. The way we did this before is by hacking it
up so that we run everything through the type dumper with a null printer,
so that the output goes to /dev/null. But really, we don't need to dump
anything, all we want to do is build the type database. Since
TypeDatabaseVisitor now exists independently of TypeDumper, we can do
this. We just build a custom visitor callback pipeline that includes a
database visitor but not a dumper.

All the hackery around printers etc goes away. After this patch, we could
probably even delete the entire CVTypeDumper class since really all it is
at this point is a thin wrapper that hides the details of how to build a
useful visitation pipeline. It's not a priority though, so CVTypeDumper
remains for now.

After this patch we will be able to easily plug in a different style of
type dumper by only implementing the proper visitation methods to dump
one-line output and then sticking it on the pipeline.

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

llvm-svn: 291724

This matches what bfd and gold do. It also matches the common flags of
other .data sections.

llvm-svn: 291674

We had an error when met this relocation
after latest changes aboult listing
x86 relocations explicitly.

Since we support R_X86_64_NONE,
and GNU ld supports R_386_NONE,
it seems reasonable to have.

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

llvm-svn: 291672

Previously some value was returned by default for relocations by getRelExpr(),
even if relocation actually was not supported.

This is orthogonal alternative to D28094.
Instead of implementing probably useless R_386_PC8/R_386_8 relocations,
this patch uses them in a testcase to demonstrate what happens
when LLD mets unsupported relocations.

Patch passes all testcases and changes logic only for x86.

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

llvm-svn: 291658

We were starting to get some name clashes between llvm-pdbdump
and the common CodeView framework, so I took this opportunity
to rename a bunch of files to more accurately describe their
usage.  This also helps in llvm-pdbdump to distinguish
between different files and whether they are used for pretty
dump mode or raw dump mode.

llvm-svn: 291627

llvm-svn: 291602

We were already dropping them from the dynamic symbol table, but the
regular symbol table was still listing them as globals.

llvm-svn: 291573

This actually simplifies the code a bit as now all local symbols are
handled uniformly.

This should fix the build of www/webkit2-gtk3.

llvm-svn: 291569

This broke the following two bots:

lld-x86_64-win7: the test failed because a diff command is not available
on that bot. That's a configuration error of the bot and will be fixed soon.

llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast: "tar xf" failed on that
bot. I suspect that it is due to the maximum path limitation on Windows.
A build directory contains a buildbot name, so it's longer than usual on
that machine. On Windows, many filesystem operations fail if a path is
longer than 255 characters. I'll try to address that in another patch.

llvm-svn: 291527

I think generated tar files are more compatible with old tar commands
because of r291494 and r291340, so I want to enable this test on buildbots.

llvm-svn: 291526

When reserving copy relocation space for a shared symbol, scan the DSO's
program headers to see if the symbol is in a read-only segment. If so,
reserve space for that symbol in a new synthetic section named .bss.rel.ro
which will be covered by the relro program header.

This fixes the security issue disclosed on the binutils mailing list at:
https://sourceware.org/ml/libc-alpha/2016-12/msg00914.html

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

llvm-svn: 291524

This is in preparation for my next change, which will introduce a relro
nobits section. That requires that relro sections appear at the end of the
progbits part of the r/w segment so that the relro nobits section can appear
contiguously.

Because of the amount of churn required in the test suite, I'm making this
change separately.

llvm-svn: 291523

Use the new --cmakedir option to obtain LLVM_CMAKE_PATH straight from
llvm-config instead of reconstructing it locally.

llvm-svn: 291502

Rafael suggested in review to wrap the `.` in an
`ABSOLUTE` op to force the section to be in the
*ABS* "section":

  * http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20170109/417865.html

llvm-svn: 291501

This patch enables something like "-o /dev/null".
Previouly, it failed because such files cannot be renamed.

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

llvm-svn: 291496

The linkonce feature is a sort of proto-comdat. As far as I am aware no
compiler produces linkonce sections anymore, but some glibc i386 object
files contain definitions of symbol "__x86.get_pc_thunk.bx" in linkonce
sections. Drop those sections to avoid duplicate symbol errors.

This is glibc PR20543, we should remove this hack once that has been
fixed for a while.

Fixes PR31215.

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

llvm-svn: 291474

This patch allows for linker scripts to assign a new value
to a symbol that is already defined (either in an object file
or the linker script itself).

llvm-svn: 291459

Summary:
Lld's build had a couple of issues which prevented a successfull
LLVM_LINK_LLVM_DYLIB compilation.

- add_llvm_library vs llvm_add_library: One adds a library to libLLVM.so, other
  one doesn't. Lld was using the wrong one, causing symbols to be mupltiply
  defined in things linking to libLLVM.
- confusion when to use LINK_LIBS vs LINK_COMPONENTS in llvm_add_library
- not using LLVM_LINK_COMPONENTS for add_lld_tool

With these fixes lld compiles and it's test suite passes both in
LLVM_LINK_LLVM_DYLIB mode and without it.

Reviewers: ruiu, beanz

Subscribers: llvm-commits, mgorny

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

llvm-svn: 291432

This patch moves convertToUnixPathSeparator from LLD to LLVM.

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

llvm-svn: 291414

Previously, files added using INCLUDE directive weren't added
to reproduce archives. In this patch, I defined a function to
open a file and use that from Driver and LinkerScript.

llvm-svn: 291413

llvm-svn: 291348

In order to keep symbol lookup a simple name lookup this patch adds
versioned symbols with an explicit @ to the symbol table.

llvm-svn: 291293

Should bring back the windows bots.

llvm-svn: 291263

llvm-svn: 291261

llvm-svn: 291257

llvm-svn: 291224

llvm-svn: 291223

The two overloaded functions hid each other. This patch merges them.

llvm-svn: 291222

Now TarWriter takes care of path separator conversion, so we don't
need to handle that in LLD.

llvm-svn: 291221

Previously, when we printed out a path obtained from DWARF debug info,
we replaced \ with / on Windows. But that doesn't make sense. We should
respect the system's path separator.

llvm-svn: 291219

llvm-svn: 291212

This is how we use TarWriter in LLD. Now LLD does not append
a file extension, so you need to pass `--reproduce foo.tar`
instead of `--reproduce foo`.

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

llvm-svn: 291210

llvm-svn: 291113

llvm-svn: 291110