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

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

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

llvm-svn: 291223

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

llvm-svn: 291222

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

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

After Mark's patch I was wondering what was the rationale for the ELF
spec requiring us to merge only sections with matching flags and
types. I tried emailing
https://groups.google.com/forum/#!forum/generic-abi, but looks like my
emails are not being posted (the list is probably moderated). I
emailed Cary Coutant instead.

Cary pointed out that the section was a late addition and didn't got
the scrutiny it deserved. Given that and the problems found by
implementing the letter of the standard, I propose changing lld to
merge all sections with the same name and issue errors if the types or
some critical flags are different.

This should allow an unmodified firefox linked with lld to run.

This also merges some code with the linkerscript path.

llvm-svn: 291107

The glibc dynamic loader rounds the size down, so without this the loader
will fail to change the memory protection for the last page.

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

llvm-svn: 290986

    
In a shared library an undefined symbol is implicitly imported. If the
symbol is called as a function a PLT entry is generated for it. When the
caller is a Thumb b.w a thunk to the PLT entry is needed as all PLT
entries are in ARM state.
    
This change allows undefined symbols to have thunks in the same way that
shared symbols may have thunks.

llvm-svn: 290951

llvm-svn: 290932

llvm-svn: 290510

This fixes issue revealed by r289961.

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

llvm-svn: 290419

We managed new MemoryBuffers in different ways in LinkerScript.cpp and
Driver.cpp. With this patch, they are managed in the same way.

llvm-svn: 290411

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

llvm-svn: 290339

This is last known noticable fatal() in target.cpp.
We also have other ones for unknown relocations or
creating unknown targets, but that one can be just error I think.

Used yaml2obj to generate test.

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

llvm-svn: 290335

Vectors returned form that function contained nullptrs or Undefined symbols.
This patch filter them out. This makes use of the function a bit easier.

llvm-svn: 290334

Previously, that was an alias to -color-diagnostics=auto. However,
Clang's -fcolor-diagnostics is an alias to -fcolor-diagnostics=always,
so that was confusing. This patch fixes that issue.

llvm-svn: 290332

Previously, you had to call initDemangledSyms() before accessing DemangledSyms.
Now getDemangledSyms() initializes it and then returns it. So it is now less easy
to use it in a wrong way.

llvm-svn: 290323

llvm-svn: 290321

llvm-svn: 290320

llvm-svn: 290318

From https://sourceware.org/binutils/docs/ld/File-Commands.html:
The file will be searched for in the current directory, and in any 
directory specified with the -L option.

Patch done by Alexander Richardson.

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

llvm-svn: 290247

DefinedSynthetic is not created for a real ELF object, so it doesn't
have to be a template function. It has a virtual st_value, which is
either 32 bit or 64 bit, but we can simply use 64 bit.

llvm-svn: 290241

We probably would want to avoid fatal() if we can in context of librarification,
but for me reason of that patch is to help D27900 go.

D27900 changes errors reporting to something like
error: text1
note: text2
note: text3

where hint used to provide additional information about location. In that case
I can't just call fatal() because user will not see notes after that what adds additional complication to handle.
So It is good to switch fatal() to error() where it is possible.

Also it adds testcase with broken relocation number. 
Previously we did not have any, It checks that error() instead of fatal() works fine.

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

llvm-svn: 290239

It was revealed by D27831.

If we have linkerscript that includes another one that sets OUTPUT for example:

RUN: echo "INCLUDE \"foo.script\"" > %t.script
RUN: echo "OUTPUT(\"%t.out\")" > %T/foo.script
then we do:

void ScriptParser::readInclude() {
...
  std::unique_ptr<MemoryBuffer> &MB = *MBOrErr;
  tokenize(MB->getMemBufferRef());
  OwningMBs.push_back(std::move(MB));
}

void ScriptParser::readOutput() {
...
    Config->OutputFile = unquote(Tok);
...
}
Problem is that OwningMBs are destroyed after script parser do its job.
So all Toks are dead and Config->OutputFile points to destroyed data.

Patch suggests to save all included scripts into using string Saver.

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

llvm-svn: 290238

Older versions of BFD generate libraries with .MIPS.abiflags that only
concatenate the individual .MIPS.abiflags sections instead of merging.

Patch by Alexander Richardson.

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

llvm-svn: 290237

llvm-svn: 290231

llvm-svn: 290215

llvm-svn: 290213

GlobPattern is a class to handle glob pattern matching. Currently
only LLD is using that, but technically that feature is not specific
to linkers, so in this patch I move that file to LLVM.

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

llvm-svn: 290212

Relocatable file does not need to have an entry symbol so the warning is
useless in that case.

llvm-svn: 290206

That was requested by Mark Kettenis in llvm-dev:

"It is the intention that .openbsd.randomdata sections are made
read-only after initialization. The native (ld.bfd based) OpenBSD
toolchain accomplishes this by including .openbsd.randomdata into the
PT_GNU_RELRO segment."

He suggested code change, I added testcase.

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

llvm-svn: 290174

This value is used only once, and we can compute a value.
So we don't need to save it.

llvm-svn: 290164