The patch implements initial support of microMIPS code linking:
  - Handle microMIPS specific relocations.
  - Emit both R1-R5 and R6 microMIPS PLT records.

For now linking mixed set of regular and microMIPS object files is not
supported. Also the patch does not handle (setup and clear) the
least-significant bit of an address which is utilized as the ISA mode
bit and allows to make jump between regular and microMIPS code without
any thunks.

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

llvm-svn: 313028

Replace OutputSection *Cmd to OutputSection *OS. The Commands vector was
moved to OutputSection but the names of the variables were not. This patch
changes the names to match.

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

llvm-svn: 313015

This fixes two more cases where we were aligning the offset in a
section, instead of the final address.

llvm-svn: 312983

When given

foobar = ALIGN(., 0x100);

my expectation from what the manual says is that the final address of
foobar will be aligned. It seems that bfd aligns the offset in the
section, which causes some odd results if the section is not 0x100
aligned. Gold aligns the address.

This changes lld to align the final address.

llvm-svn: 312979

When building COFF programs many targets such as mingw prefer
to have a gnu ld frontend. Rather then having a fully fledged
standalone driver we wrap a shim around the LINK driver.

Extra tests were provided by mstorsjo

Reviewers: mstorsjo, ruiu

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

llvm-svn: 312926

llvm-svn: 312823

llvm-svn: 312820

llvm-svn: 312812

We handled all undefined symbols before this.

llvm-svn: 312808

llvm-svn: 312807

This allows combining --dynamic-list and version scripts too. The
version script controls which symbols are visible, and
--dynamic-list controls which of those are preemptible.

Unlike previous versions, undefined symbols are still considered
preemptible, which was the issue breaking the cfi tests.

This fixes pr34053.

llvm-svn: 312806

to separate commons based on file name patterns. The following linker script
construct does not work because commons are allocated before section placement
is done and the only synthesized BssSection that holds all commons has no file
associated with it:
SECTIONS { .common_0 : { *file0.o(COMMON) }}

This patch changes the allocation of commons to create a section per common
symbol and let the section logic do the layout.

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

llvm-svn: 312796

llvm-svn: 312789

llvm-svn: 312787

REGION_ALIAS(alias, region)

Alias names can be added to existing memory regions created with
the MEMORY command. Each name corresponds to at most one
memory region.

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

llvm-svn: 312777

This reverts commit r312757.

Evgenii Stepanov reports that it broke some tests.

llvm-svn: 312771

If --dynamic-list is given, only those symbols are preemptible.

This allows combining --dynamic-list and version scripts too. The
version script controls which symbols are visible, and --dynamic-list
controls which of those are preemptible.

This fixes pr34053.

llvm-svn: 312757

llvm-svn: 312753

To support errata patching on AArch64 we need to be able to overwrite
an arbitrary instruction with a branch. For AArch64 it is sufficient to
always write all the bits of the branch instruction and not just the
immediate field. This is safe as the non-immediate bits of the branch
instruction are always the same.

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

llvm-svn: 312727

As was suggested in D34956 thread.

llvm-svn: 312712

It is a bit more convinent and helps to simplify logic 
of program headers allocation a little.

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

llvm-svn: 312711

The default padding for an executable segment is the target trap
instruction which for x86_64 is 0xCC. However, the .eh_frame section
requires the padding to be zero. The code that writes the .eh_frame
section assumes that its segment is zero initialized and does not
explicitly write the zero padding. This does not work when the .eh_frame
section is in the executable segment (for example when using
-no-rosegment).

This patch changes the .eh_frame writing code to explicitly write the
zero padding.

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

llvm-svn: 312706

If using --format=binary with an input file name that has one or more non-ascii
characters in, LLD has undefined behaviour (it crashes on my Windows Debug build)
when calling isalnum with these non-ascii characters. Instead, of calling
std::isalnum, this patch uses an internal version that ignores the locale and
checks a specific subset of characters.

Reviewers: ruiu

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

llvm-svn: 312705

llvm-svn: 312675

llvm-svn: 312669

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

llvm-svn: 312656

llvm-svn: 312655

The R_AARCH64_LDST<N>_ABS LO12_NC relocations where N is 8, 16, 32, 64 or
128 have a scaled immediate. For example R_AARCH64_LDST32_ABS_LO12_NC
shifts the calculated value right by 4. If the target symbol + relocation
addend is not aligned properly then bits of the answer will be lost.

This change adds an alignment check to the relocations to make sure the
target of the relocation is aligned properly. This matches the behavior of
GNU ld. The motivation is to catch ODR violations such as a declaration of
extern int foo, but a definition of bool foo as the compiler may use
R_AARCH64_LDST32_ABS_LO12_NC for the former, but not align the destination.

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

llvm-svn: 312637

The fixSectionAlignments() function may alter the alignment of some
OutputSections, this is likely to alter the addresses calculated earlier
in assignAddresses(). By moving the call to fixSectionAlignments() we
make sure that assignAddresses() is consistent with the early calculation
used for RangeThunks and the final call just before writing the image.

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

llvm-svn: 312636

The --symbol-ordering-file path was not being rewritten in the response file when
using --reproduce. This patch adds this to the list of switches that are rewritten,
so that the path is somewhere within the reproducer directory tree.

Reviewers: ruiu

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

llvm-svn: 312626

Previously LLD did not calculate LMAOffset correctly when
AT and MEMORY were used together.

Patch fixes PR34407.

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

llvm-svn: 312625

std::vector::insert invalidates all iterators, so it was not safe to do

  Script->Opt.Commands.insert(++I, Make(ElfSym::End1));
  Script->Opt.Commands.insert(++I, Make(ElfSym::End2));

because after the first line, `I` is no longer valid.

This patch rewrites fixes the issue. I belive the new code without
higher-order functions is a bit more readable than before.

llvm-svn: 312570

It appears that a potential race between the cache client and the cache
pruner that I thought was unlikely actually happened in practice [1].
Try to avoid the race condition by opening the temporary file before
renaming it. Do this only on non-Windows platforms because we cannot
rename open files on Windows using the sys::fs::rename function.

[1] https://luci-logdog.appspot.com/v/?s=chromium%2Fbb%2Fchromium.memory%2FLinux_CFI%2F1610%2F%2B%2Frecipes%2Fsteps%2Fcompile%2F0%2Fstdout

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

llvm-svn: 312567

Pass BSIZE and SHIFT as a function arguments to the `writeRelocation`
routine. It does not make a sense to have so many `writeRelocation's`
instances.

llvm-svn: 312495

llvm-svn: 312494

Having p_filesz different from p_memsz is confusing some tools.

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

llvm-svn: 312384

Previously it was called twice for .comment synthetic section.
That created 2 pieces of data, which was deduplicated anyways,
but was not clean.

llvm-svn: 312327

The problem with symbol assignments in implicit linker scripts is that
they can refer synthetic symbols such as _end, _etext or _edata. The
value of these symbols is currently fixed only after all linker script
commands are processed, so these assignments will be using non-final and
hence invalid value.

Rather than fixing the symbol values after all command processing have
finished, we instead change the logic to generate symbol assignment
commands that set the value of these symbols while processing the
commands, this ensures that the value is going to be correct by the time
any reference to these symbol is processed and is equivalent to defining
these symbols explicitly in linker script as BFD ld does.

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

llvm-svn: 312305

llvm-svn: 312233

llvm-svn: 312231