Summary: When we encouter a relocation type we don't know how to handle, this change causes us to print out the hexadecimal value of the relocation type. This makes troubleshooting a little easier.
Reviewers: ruiu, zturner
Differential Revision: https://reviews.llvm.org/D28576
llvm-svn: 291962
The freebsd dynamic linker doesn't check if the value is null (and it
is reasonable for it to do that). That means that producing a .so with
a null DT_INIT/DT_FINI causes the base address to be called.
This should fix the libreoffice build.
llvm-svn: 291944
These were 3 last synthetics that were added in addPredefinedSections() instead
of createSyntheticSections(). Now it is possible to move addition to correct common place.
Also patch fixes testcase which discards .shstrtab, by restricting doing that.
Differential revision: https://reviews.llvm.org/D28561
llvm-svn: 291908
The effect is that the nobits section gets space allocated on disk.
Both bfd and gold allow this with linker scripts. To try to keep
things simple in lld, always allow it for now.
llvm-svn: 291795
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
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
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
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
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
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
Peter Collingbourne