In preparation for supporting range extension thunks we now continually
call createThunks() until no more thunks are added. This requires us to
record the thunks we add on each pass and only merge the new ones into the
OutputSection. We also need to check if a Relocation is targeting a thunk
to prevent us from infinitely creating more thunks.
    
Differential Revision: https://reviews.llvm.org/D34034

llvm-svn: 305555

llvm-svn: 305520

Obviously the paths are going to be machine dependent, so
don't try to match them in the test.

llvm-svn: 305518

This resubmits commit c0c249e9f2ef83e1d1e5f166b50673d92f3579d7.

It was broken due to some weird template issues, which have
since been fixed.

llvm-svn: 305517

llvm-svn: 305514

This is probably the main patch left in unifying our intermediary
representation.

It moves the creation of default commands before section sorting. This
has the nice effect that we now have one location where we decide
where an orphan section should be placed.

Before this patch sortSections would decide the relative location of
orphan sections to other sections, but it was up to placeOrphanSection
to decide on the exact location.

We now only sort sections we created since the linker script is
already in the correct order.

llvm-svn: 305512

This reverts commit 83ea17ebf2106859a51fbc2a86031b44d33696ad.

This is failing due to some strange template problems, so reverting
until it can be straightened out.

llvm-svn: 305505

When link is invoked with `/def:` and no input files, it behaves as if
`lib.exe` was invoked.  Emulate this behaviour, generating the import
library from the def file that was passed.  Because there is no input to
actually generate the dll, we simply process the def file early and exit
once we have created the import library.

llvm-svn: 305502

After some internal discussions, we agreed that the raw output style had
outlived its usefulness. It was originally created before we had even
thought of dumping to YAML, and it was intended to give us some insight
into the internals of a PDB file. Now we have YAML mode which does
almost exactly this but is more powerful in that it can round-trip back
to a PDB, which the raw mode could not do. So the raw mode had become
purely a maintenance burden.

One option was to just delete it. However, its original goal was to be
as readable as possible while staying close to the "metal" - i.e.
presenting the output in a way that maps directly to the underlying file
format. We don't actually need that last requirement anymore since it's
covered by the yaml mode, so we could repurpose "raw" mode to actually
just be as readable as possible.

This patch implements about 80% of the functionality previously in raw
mode, but in a completely different style that is more akin to what
cvdump outputs. Records are very compressed, often times appearing on
just one line. One nice thing about this is that it makes full record
matching easier, because you can grep for indices, names, and leaf types
on a single line often.

See the tests for some examples of what the new output looks like.

Note that this patch actually regresses the functionality of raw mode in
a few areas, but only because the patch was already unreasonably large
and going 100% would have been even worse. Specifically, this patch is
missing:

The ability to dump module debug subsections (checksums, lines, etc)
The ability to dump section headers
Aside from that everything is here. While goign through the tests fixing
them all up, I found many duplicate tests. They've been deleted. In
subsequent patches I will go through and re-add the missing
functionality.

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

llvm-svn: 305495

This is necessary to ensure that sections containing symbols referenced
from linker scripts (e.g. in data commands) don't get GC'd.

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

llvm-svn: 305452

Reviewers: ruiu, rafael, grimar, atanasyan, psmith, dylanmckay

Reviewed By: ruiu, rafael, grimar, dylanmckay

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

llvm-svn: 305444

llvm-svn: 305428

I added the same function in llvm, so this is causing an
ambiguous symbol.

llvm-svn: 305412

We do not actually accept .rc files. We only accept .res files.

Pointed out by Eric Beckmann.

llvm-svn: 305406

This was originally reverted because of some non-deterministic
failures on certain buildbots.  Luckily ASAN eventually caught
this as a stack-use-after-scope, so the fix is included in
this patch.

llvm-svn: 305393

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

llvm-svn: 305375

Summary: I found that getString defined in the LLD's Driver.cpp is
exactly the same as Arg::getLastArgValue defined in
llvm/Option/ArgLIst.h. This patch removes that local function and use
the function that the Arg class provides.

Reviewers: ruiu

Subscribers: emaste, llvm-commits

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

llvm-svn: 305374

This is causing failures on linux bots with an invalid stream
read.  It doesn't repro in any configuration on Windows, so
reverting until I have a chance to investigate on Linux.

llvm-svn: 305371

This allows us to use yaml2obj and obj2yaml to round-trip CodeView
symbol and type information without having to manually specify the bytes
of the section. This makes for much easier to maintain tests. See the
tests under lld/COFF in this patch for example. Before they just said
SectionData: <blob> whereas now we can use meaningful record
descriptions. Note that it still supports the SectionData yaml field,
which could be useful for initializing a section to invalid bytes for
testing, for example.

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

llvm-svn: 305366

Summary: Pointed out by Yuka Takahashi.

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

llvm-svn: 305364

llvm-svn: 305341

This is similar to what we do for InputSections and makes them easier
to access.

llvm-svn: 305337

llvm-svn: 305333

Currently we do layout as if non alloc sections had an actual address
and then set it to zero. This produces a few odd results where a
symbol has an address that is inconsistent with the section address.

The simplest way to fix it is probably to just set the address earlier.

The behavior of bfd seems to be similar, but it only sets the non
alloc section address is missing from the linker script or if the
script has an explicit " : 0" setting the address of the output
section (which the default script does).

llvm-svn: 305323

This means that 'llvm-pdbutil' in test commands will resolve
to the absolute path to the tool, in line with what happens
already for other tools.

This works either way because the bin directory is also
prepended to the PATH.  I'm not sure why both methods are
used.

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

llvm-svn: 305297

Summary:
Expose the module descriptor index and fill it in for section
contributions.

Reviewers: zturner

Subscribers: llvm-commits, ruiu, hiraditya

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

llvm-svn: 305296

We have two .s test files in lld/test/COFF that weren't being run as
part of check-lld. They both pass locally for me.

llvm-svn: 305295

llvm-svn: 305260

This shows an oddity of this output. While the section address is 0,
the the symbol address is computed as if the section was allocatable.

llvm-svn: 305250

The last fix required the user to manually add the required
feature.  This caused an LLD test to fail because I failed to
update LLD.  In practice we can hide this logic so it can just
be transparently added when we write the PDB.

llvm-svn: 305236

The new metadata is easier to manipulate than module flags.

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

llvm-svn: 305227

The ELF standard defines that the SHT_GROUP section as follows:

 - its sh_link has the symbol index, and
 - the symbol name is used to uniquify section groups.

Object files created by GNU gold does not seem to comply with the
standard. They have this additional rule:

 - if the symbol has no name and a STT_SECTION symbol, a section
   name is used instead of a symbol name.

If we don't do anything for this, the linker fails with a mysterious
error message if input files are generated by gas. It is unfortunate
but I think we need to support it.

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

llvm-svn: 305218

Given

.weak target
 .global _start
_start:
 b target

The intention is that the branch goes to the instruction after the
branch, effectively turning it on a nop.  The branch adds the runtime
PC, but we were adding it statically too.

I noticed the oddity by inspection, but llvm-objdump seems to agree,
since it now prints things like:

b       #-4 <_start+0x4>

llvm-svn: 305212

Relocations referring to merge sections are considered equal if they
resolve to the same offset in the same output section.

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

llvm-svn: 305177

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

llvm-svn: 305176

llvm-svn: 305156

llvm-svn: 305145

Currently the freebsd early boot code fails to link. The issue reduces
to 16 bit code at position 0x7000 wanting to jump to position
0x9000. That is represented in the .o file as a relocation with no
symbol and an addend of 0x9000 - 2 (The -2 is because i386 uses the ip
after the current instruction for jumps).

If the addend is interpreted as signed (it should), it is -28674. In a
32 bit architecture, that is the address 0xffff8ffe. To get there from
0x7000 we have to add 4294909950 (too big) or subtract 57346 (too
small). We then produce an error.

What lld is missing is the fact that at runtime this will actually be
a 16 bit architecture and adding 0x1ffe produces 0x8ffe which is the
correct result in 16 bits (-28674).

Since we have a 16 bit addend and a 16 bit PC, the relocation can move
the PC to any 16 bit address and that is the only thing we really need
to check: if the address we are pointing to fits in 16 bits. This is
unfortunately hard to do since we have to delay subtracting the PC and
if we want to do that outside of Target.cpp, we have to move the
overflow check out too.  An incomplete patch that tries to do that is
at https://reviews.llvm.org/D34070

This patch instead just relaxes the check. Since the value we have is
the destination minus the PC and the PC is 16 bits, it should fit in
17 bits if the destination fits in 16 too.

bfd had a similar issue for some time and got a similar fix:
https://sourceware.org/ml/binutils/2005-08/msg00001.html

llvm-svn: 305135

SHF_GROUP bit doesn't make sense in executables or DSOs, so linkers are
expected to remove that bit from section flags. We did that when we create
output sections.

This patch is to do that earlier than before. Now the flag is dropped when
we instantiate input section objects.

This change improves ICF. Previously, two sections that differ only in
SHF_GROUP flag were not merged, because when the control reached ICF,
the flag was still there. Now the flag is dropped before reaching to ICF,
so the difference is ignored naturally.

This issue was found by pcc.

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

llvm-svn: 305134

llvm-svn: 305112