llvm-svn: 273140

There are two motivations for this patch. The first one is a preparation
for support MIPS TLS relocations. It might sound like a joke but for GOT
entries related to TLS relocations MIPS ABI uses almost regular approach
with creation of dynamic relocations for each GOT enty etc. But we need
to separate these 'regular' TLS related entries from MIPS specific local
and global parts of GOT. ABI declare simple solution - all TLS related
entries allocated at the end of GOT after local/global parts. The second
motivation it to support GOT relocations for non-preemptible symbols
with addends. If we have more than one GOT relocations against symbol S
with different addends we need to create GOT entries for each unique
Symbol/Addend pairs.

So we store all MIPS GOT entries in separate containers. For non-preemptible
symbols we have to maintain two data structures. The first one is MipsLocal
vector. Each entry corresponds to the GOT entry from the 'local' part
of the GOT contains the symbol's address plus addend. The second one
is MipsLocalMap. It is a map from Symbol/Addend pair to the GOT index.

Differential Revision: http://reviews.llvm.org/D21297

llvm-svn: 273127

llvm-svn: 273006

llvm-svn: 273004

Doing that in an anonymous version is a bit silly, but this opens the
way for supporting it in general.

Since we don't support actual versions, for now we just disable the
version script if we detect that it is missing a local.

llvm-svn: 273000

I think it is me who named these variables, but I always find that
they are slightly confusing because align is a verb.
Adding four letters is worth it.

llvm-svn: 272984

llvm-svn: 272976

llvm-svn: 272975

llvm-svn: 272974

llvm-svn: 272973

llvm-svn: 272972

They are equivalent in C (and in C++ in this case).

llvm-svn: 272942

Patch updates the version script parser to parse versioned files.
In a simple way, just adding them to VersionScriptGlobals list.

Differential revision: http://reviews.llvm.org/D21439

llvm-svn: 272934

llvm-svn: 272924

llvm-svn: 272923

llvm-svn: 272917

llvm-svn: 272915

PltZero (or PLT[0]) was an appropriate name for the little code
we have at beginning of the PLT section when we only supported x86
since the code for x86 just fits in the first PLT slot.

It's not the case anymore. The code for ARM64 occupies first two
slots, so PltZero spans PLT[0] and PLT[1], for example.
This patch renames it to avoid confusion.

llvm-svn: 272913

For ARM and MIPS, we don't need to call this function.
This patch passes a symbol instead of a PLT entry address
so that the target handler can call it if necessary.

llvm-svn: 272910

llvm-svn: 272892

    
    Add support for the R_ARM_THM relocations used in the objects present
    in arm-linux-gnueabihf-gcc. These are:
    R_ARM_THM_CALL
    R_ARM_THM_JUMP11
    R_ARM_THM_JUMP19
    R_ARM_THM_JUMP24
    R_ARM_THM_MOVT_ABS
    R_ARM_THM_MOVW_ABS_NC
    
    Interworking between ARM and Thumb is partially supported with BLX.
    The R_ARM_CALL relocation for ARM instructions and R_ARM_THM_CALL
    relocation for Thumb instructions will write out a BL or BLX depending
    on the state of the Target.
    
    Assumptions:
    - Availability of BLX and extended range of Thumb 4-byte Branch
      instructions.
    - In relocateOne if (Val & 0x1) == 1 target is Thumb, 0 is ARM.
      This will hold for objects that comply with the ABI for the
      ARM architecture.
    
    This is sufficient for hello world to work with a recent
    arm-linux-gnueabihf distribution.
    
    Limitations:
    No interworking for R_ARM_JUMP24, R_ARM_THM_JUMP24, R_ARM_THM_JUMP19
    and the deprecated R_ARM_PLT32 and R_ARM_PC24 instructions as these
    cannot be written out as a BLX and need a state change thunk.
    
    No range extension thunks. The R_ARM_JUMP24 and R_ARM_THM_CALL have a
    range of 16Mb

llvm-svn: 272881

We were dropping the CanOmitFromDynSym bit when creating undefined
symbols because of comdat.

llvm-svn: 272812

This should never happen with correct programs, but it is trivial
write a testcase where lld would crash or report duplicated
symbols. We now behave like when an archive is used and include the
file only once.

llvm-svn: 272724

llvm-svn: 272719

Previously message told us that relocations could
not be used when making shared object. That was
correct because message could appear (and it is expected) 
when we linked executable.
Message should have being changed to something
that says we can't use a subset of relocations against shared
symbols.

Patch fixes the text.

llvm-svn: 272478

llvm-svn: 272475

Just for consistency with other parts of the code.

llvm-svn: 272390

llvm-svn: 272389

In isPreemptible routine we interested in R_MIPS_GPREL16 relocation
only. This relocation fits 0xf. So the new mask 0xff is just to conform
the ABI specification.

llvm-svn: 272388

It was reported in PR28020, that lld does not link code which
gold do. But in fact that is expected behavior as we do not
support DT_TEXTREL.

This patch changes error message as it can report about relocations against
text segments exclusively, other dynamic relocations errors can 
be handled separately.

Differential revision: http://reviews.llvm.org/D21133

llvm-svn: 272377

llvm-svn: 272305

It produces an error, so that was a bad name.

llvm-svn: 272304

They point to a shared library, so they would still overflow at runtime.

llvm-svn: 272303

We can now use this to decide whether to emit a verneed during the final
pass over the symbols. We were previously wrongly creating a verneed entry
in the case where all references to a DSO's symbols were weak.

In a future change we may also want to use the used bit to control whether
shared symbols are preemptible and appear in the dynsym. This seems a little
tricky to do at the moment because isNeeded() is templated.

The only other functional change here is that we emit a DT_NEEDED for DSOs
whose symbols are all preempted by objects that appear later in the link. But
that doesn't seem too important to me.

Differential Revision: http://reviews.llvm.org/D21171

llvm-svn: 272282

We should not ignore the symbol, just the version.

Fixes error with -z defs.

llvm-svn: 272270

llvm-svn: 272265

If the symbol is local we don't need to create a R_X86_64_DTPOFF64, we
can just write the correct value in the got.

Should fix pr28018.

llvm-svn: 272205

llvm-svn: 272146

It was one line global static function that looks nicer to inline,
patch do that.

llvm-svn: 272137

llvm-svn: 272134