Recommit r294464 "[ELF] - Added partial support for --emit-relocs (no --gc-section case, no /DISCARD/ support) #3"

with temporarily file name fix in testcase.

Original commit message:

-q, --emit-relocs - Generate relocations in output

Simplest implementation: 
* no GC case, 
* no "/DISCARD/" linkerscript command support.

This patch is extracted from D28612 / D29636,

Relative to PR31579.

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

llvm-svn: 294469

Reverted r294464 "[ELF] - Added partial support for --emit-relocs (no --gc-section case, no /DISCARD/ support) #3"

Broked build bot:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/5835/steps/test/logs/stdio

llvm-svn: 294466

-q, --emit-relocs - Generate relocations in output

Simplest implementation: 
* no GC case, 
* no "/DISCARD/" linkerscript command support.

This patch is extracted from D28612 / D29636,

Relative to PR31579.

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

llvm-svn: 294464

This reverts commit r294346. Looks like it regressed the build of
magenta.

llvm-svn: 294460

OUTPUT_ARCH command can contain architecture values separated with ":", like:
OUTPUT_ARCH(i386:x86-64)

We did not support that, because got 3 lexer tokens here after recent changes.

This trivial patch fixes the issue, now whole expression inside 
OUTPUT_ARCH is just ignored.

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

llvm-svn: 294432

LLD already parses ALIGN expression to specifiy alignment for output
sections in linker scripts but it never applies the alignment to the
output section. This change handles that.

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

llvm-svn: 294374

We now just keep the address the section would have if it was
allocatable. Only the writer ignores it at the very end.

llvm-svn: 294346

{ global : local; local: *; };

llvm-svn: 294343

DefinedSynthetic symbols are attached to sections,
for the case when such symbol was attached to non-allocated section,
we calculated its value incorrectly.

We subtracted Body->Section->Addr, but non-allocatable sections
should have zero VA in output and therefore result value was wrong.

And at the same time we have Body->Section->Addr != 0 for them 
internally because  use it for calculation of section size.

Patch fixes calculation of such symbols values.

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

llvm-svn: 294322

We had assignSymbol and assignSectionSymbol methods which has similar functionality.
Patch removes one of copy and reuses another in code.

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

llvm-svn: 294290

Previously we did not do that. For example, for R_386_PC8, 
0xFF addend was not treated as 0xFFFFFFFF(-1), 
but was 0x000000FF.

Recently added checks for R_386_PC8/R_386_PC16 failed because of calculation 
overflow as a result.

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

llvm-svn: 294289

If relocations don't have addends, addends are embedded in operands.
getImplicitAddend is a function to read addends. Addends can be
negative numbers, so the return type of the function should be a
signed integer type.

llvm-svn: 294253

We now create a dummy section with index 1 before processing the
linker script.

Thanks to George Rimar for finding the bug and providing the initial
testcase.

llvm-svn: 294252

llvm-svn: 294117

Now that each OutputSectionCommand maps to just one OutputSection, we
can remove a few std::vectors.

llvm-svn: 294060

llvm-svn: 294057

Now that it doesn't impact which sections are merged, this is not a
problem.

llvm-svn: 294054

Now that we combine multiple synthetic merge section into one output
section there is no point in trying to propagate a value.

llvm-svn: 294048

This is a fix for Bugzilla 31813.

The problem is that the tokenizer does not create a separate token for
":" unless there's white space before it. Changed it to always create
a token for ":" and reworked some logic that relied on ":" being
attached to some tokens like "global:" and "local:".

llvm-svn: 294006

With a synthetic merge section we can have, for example, a single
.rodata section with stings, fixed sized constants and non merge
constants.

I can be simplified further by not setting Entsize, but that is
probably better done is a followup patch.

This should allow some cleanup in the linker script code now that
every output section command maps to just one output section.

llvm-svn: 294005

Summary: llvm/CodeGen/CommandFlags.h a utility function InitTargetOptionsFromCodeGenFlags which is used to set target options from flags based on the command line. The command line flags are stored in globals defined in the same file, and including the file in multiple places causes the globals to be defined multiple times, leading to linker errors. This change adds a single place in lld where these globals are defined and exports only the utility function. This makes it possible to call InitTargetOptionsFromCodeGenFlags from multiple places in lld, which a follow-up change will do.

Reviewers: davide, ruiu

Reviewed By: davide, ruiu

Subscribers: mgorny

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

llvm-svn: 293965

llvm-svn: 293963

llvm-svn: 293854

ld.bfd doesn't handle `-z stack-size=0` as a special case.
We shouldn't do that too.

llvm-svn: 293849

Instead of creating multiple PHDRs in a single loop, this patch
runs one for loop for each PHDR type. I think this improves code
readability.

llvm-svn: 293832

There could be multiple discontiguous output .note sections in which
case we need to put these into separate PT_NOTE segments rather then
placing them into a single segment. Where possible, we could reorder
the input sections to make sure that all .note are layed out next to
each other to avoid creation multiple PT_NOTE segments, but even in
that case, it's still possible to construct a discontiguous case e.g.
by using a linker script.

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

llvm-svn: 293811

This is a fix for Bugzilla 28579.

The problem is that in --reproduce links the file path in -o option is
copied verbatim. When "lld @response.txt" link is run against the
extracted test case, if -o contains anything other that a plain file
name, the link will likely fail because the target directory in -o may
not exists. Stripping the directory path will create the output file
in the top level test directory.

Patch by Dmitry Mikulin!

llvm-svn: 293792

    
Thunks are now implemented by redirecting the relocation to the
symbol S, to a symbol TS in a Thunk. The Thunk will transfer control
to S. This has the following implications:
- All the side-effects of Thunks happen within createThunks()
- Thunks are no longer stored in InputSections and Symbols no longer
  need to hold a pointer to a Thunk
- The synthetic Thunk sections need to be merged into OutputSections
    
This implementation is almost a direct conversion of the existing
Thunks with the following exceptions:
- Mips LA25 Thunks are placed before the InputSection that defines
  the symbol that needs a Thunk.
- All ARM Thunks are placed at the end of the OutputSection of the
  first caller to the Thunk.
    
Range extension Thunks are not supported yet so it is optimistically
assumed that all Thunks can be reused.

This is a recommit of r293283 with a fixed comparison predicate as
std::merge requires a strict weak ordering.

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

llvm-svn: 293757

llvm-svn: 293751

Accidentally lost the commit title and message,
will recommit.

llvm-svn: 293750

llvm-svn: 293749

This is alternative to D28857 which was incorrect.

One of linux scripts contains:

vvar_start = . - 2 * (1 << 12);
vvar_page = vvar_start;
vvar_vsyscall_gtod_data = vvar_page + 128;
Previously we did not mark first expression as non-absolute,
though it contains location counter.

And LLD failed with error:
relocation R_X86_64_PC32 cannot refer to absolute symbol

This patch should fix the issue, and opens road for doing the same for other operators
(though not clear if that is needed).

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

llvm-svn: 293748

Previously, we were printing out something like this for
sections/symbols with alignment 16

  0000000000201000 0000000000000182    10 .data

which I think confusing. I think printing it in decimal is better.

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

llvm-svn: 293685

It is not clear what we should do when overflow occurs for these
relocations because the relocations are not an official part of
the i386 psABI. But checking for overflow is generally a good to do
and is consistent with other relocations such as R_X86_64_8.

llvm-svn: 293683

Our reporting for that case was just like:
ld.lld: error: do not know how to handle relocation 'R_386_PC8' (23)
It did not give any information about error location.

Patch adds filename to error.

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

llvm-svn: 293640

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

llvm-svn: 293613

Linux kernel linkerscript contains additional semicolon (last line):

.apicdrivers : AT(ADDR(.apicdrivers) - LOAD_OFFSET) {
  __apicdrivers = .;
  *(.apicdrivers);

I checked that both gold and bfd are able to parse something like:

.text : { ;;*(.text);;S = 0;; } }

Patch do the same.

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

llvm-svn: 293612

If no bss sections appear after the relro segment, the loader will round
the r/w segment size to the target's page size. Align the relro size in the
same way to ensure that it does not extend past the end of the program's
own memory region.

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

llvm-svn: 293519

llvm-svn: 293452

llvm-svn: 293409