llvm-svn: 273074

Make that explicit.

llvm-svn: 273013

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

This is a reduction from the only symbol in a build of clang that the
gold plugin internalizes but lld does not.

llvm-svn: 272845

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

Part of the fix for PR27553.

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

llvm-svn: 272711

llvm-svn: 272596

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

Initially we wanted to check that these two relocations are not present when linking DSO because of 
possible overflow in runtime. Patch moves them to writable segment in testcases to allow
proper error check to trigger.
Otherwise error message about using dynamic relocations against text segment was shown.

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

llvm-svn: 272379

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

llvm-svn: 272302

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