Summary:
I also changed the message to print both the ISA and the the architecture
name for incompatible files. Previously it would be quite hard to find the
actual path of the incompatible object files in projects that have many
object files with the same name in different directories.

Reviewers: atanasyan, ruiu

Reviewed By: atanasyan

Subscribers: emaste, sdardis, llvm-commits

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

llvm-svn: 320056

microMIPS symbols including microMIPS PLT records created for regular
symbols needs to be marked by STO_MIPS_MICROMIPS flag in a symbol table.
Additionally microMIPS entries in a dynamic symbol table should have
configured less-significant bit. That allows to escape teaching a
dynamic linker about microMIPS symbols.

llvm-svn: 318097

Summary:
The COFF linker and the ELF linker have long had similar but separate
Error.h and Error.cpp files to implement error handling. This change
introduces new error handling code in Common/ErrorHandler.h, changes the
COFF and ELF linkers to use it, and removes the old, separate
implementations.

Reviewers: ruiu

Reviewed By: ruiu

Subscribers: smeenai, jyknight, emaste, sdardis, nemanjai, nhaehnle, mgorny, javed.absar, kbarton, fedor.sergeev, llvm-commits

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

llvm-svn: 316624

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

llvm-svn: 316460

If symbol has the STO_MIPS_MICROMIPS flag and requires a thunk to perform
call PIC from non-PIC functions, we need to generate a thunk with microMIPS
code.

llvm-svn: 314797

Currently LLD calls the `isMicroMips` routine to determine type of PLT entries
needs to be generated: regular or microMIPS. This routine checks ELF
header flags in the `FirstObj` to retrieve type of linked object files.
So if the first file does not contain microMIPS code, LLD will generate
PLT entries with regular (non-microMIPS) code only.

Ideally, if a PLT entry is referenced by microMIPS code only this entry
should contain microMIPS code, if a PLT entry is referenced by regular
code this entry should contain regular code. In a "mixed" case the PLT
entry can be either microMIPS or regular, but each "cross-mode-call" has
additional cost.

It's rather difficult to implement this ideal solution. But we can
assume that if there is an input object file with microMIPS code, the
most part of the code is microMIPS too. So we need to deduce type of PLT
entries based on finally calculated ELF header flags and do not check
only the first input object file.

This change implements this.
  - The `getMipsEFlags` renamed to the `calcMipsEFlags`. The function
    called from the `LinkerDriver::link`. Result is stored in
    the Configuration::MipsEFlags field.
  - The `isMicroMips` and `isMipsR6` routines access the `MipsEFlags`
    field to get and check calculated ELF flags.
  - New types of PLT records created when necessary.

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

llvm-svn: 314675

This patch removes lot of static Instances arrays from different input file 
classes and introduces global arrays for access instead. Similar to arrays we
have for InputSections/OutputSectionCommands.

It allows to iterate over input files in a non-templated code.

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

llvm-svn: 313619

Rename it because it was too easy to conflict with llvm::object::ObjectFile
which broke buildbots several times.

llvm-svn: 309199

NFC, just makes it easier to access from non templated code.

llvm-svn: 309152

llvm-svn: 308297

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

llvm-svn: 305742

This creates a new library called BinaryFormat that has all of
the headers from llvm/Support containing structure and layout
definitions for various types of binary formats like dwarf, coff,
elf, etc as well as the code for identifying a file from its
magic.

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

llvm-svn: 304864

In short the patch introduces support for linking object file conform
MIPS N32 ABI [1]. This ABI is similar to N64 ABI but uses 32-bit
pointer size.

The most non-trivial requirement of this ABI is one more relocation
packing format. N64 ABI puts multiple relocation type into the single
relocation record. The N32 ABI uses series of successive relocations
with the same offset for this purpose. In this patch, new function
`mergeMipsN32RelTypes` handle this case and "convert" N32 relocation to
the N64 relocation so the rest of the code keep unchanged.

For now, linker does not support series of relocations applied to sections
without SHF_ALLOC bit. Probably later I will add the support or insert
some sort of assert into the `relocateNonAlloc` routine to catch this
case.

[1] ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/MIPS-N32-ABI-Handbook.pdf

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

llvm-svn: 286052

If we have input without object files, for example if we have only .so
code crashes in checkFlags(), getPicFlags(), getArchFlags() functions.

Patch fixes the issue.

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

llvm-svn: 283226

It's better because it's a verb.

llvm-svn: 282763

Previously, all input files were owned by the symbol table.
Files were created at various places, such as the Driver, the lazy
symbols, or the bitcode compiler, and the ownership of new files
was transferred to the symbol table using std::unique_ptr.
All input files were then free'd when the symbol table is freed
which is on program exit.

I think we don't have to transfer ownership just to free all
instance at once on exit.

In this patch, all instances are automatically collected to a
vector and freed on exit. In this way, we no longer have to
use std::unique_ptr.

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

llvm-svn: 281425

This section supersedes .reginfo and .MIPS.options sections. But for now
we have to support all three sections for ABI transition period.

llvm-svn: 278482

llvm-svn: 278480

llvm-svn: 278473

llvm-svn: 278392

llvm-svn: 278352

[ELF][MIPS] Take into account combination of EF_MIPS_ARCH and EF_MIPS_MACH flags while checking ISA compatibility

MIPS ISA encoded using two ELF flags: general architecture flag like
EF_MIPS_ARCH_32, EF_MIPS_ARCH_64R6 etc and optional machine variant flag
like EF_MIPS_MACH_4111, EF_MIPS_MACH_OCTEON3 etc. When we check
compatibility between two input files and deduce ELF flags for generated
output we need to take into account both of these flags.

llvm-svn: 278230

Previously, we incrementally updated the reuslting flag as we check
file flags, so it was not very clear who is updating what flags.
This patch makes them pure functions -- that has no side effect and
don't update arguments to improve readability.

Now each function construct a patial result, and all resutls are then
bitwise-OR'ed to construct the final result.

This patch also creates a new file, Mips.cpp, to move all these
MIPS functions to a separate file.

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

llvm-svn: 278042