Skip to content
  1. Dec 07, 2017
  2. Nov 29, 2017
    • Peter Smith's avatar
      [ELF][AArch64] Add support for AArch64 range thunks. · 31dddc97
      Peter Smith authored
      The AArch64 unconditional branch and branch and link instructions have a
      maximum range of 128 Mib. This is usually enough for most programs but
      there are cases when it isn't enough. This change adds support for range
      extension thunks to AArch64. For pc-relative thunks we follow the small
      code model and use ADRP, ADD, BR. This has a limit of 4 gigabytes.
      
      Differential Revision: https://reviews.llvm.org/D39744
      
      llvm-svn: 319307
      31dddc97
  3. Nov 27, 2017
    • Peter Smith's avatar
      [ELF][ARM] Refine check for when undefined weak needs a Thunk · 2809926c
      Peter Smith authored
      When an undefined weak reference has a PLT entry we must generate a range
      extension thunk for any B or BL that can't reach the PLT entry.
      
      This change explicitly looks for whether a PLT entry exists rather than
      assuming that weak references never need PLT entries unless Config->Shared
      is in operation. This covers the case where we are linking an executable
      with dynamic linking, hence a PLT entry will be needed for undefined weak
      references. This case comes up in real programs over 32 Mb in size as there
      is a B to a weak reference __gmon__start__ in the Arm crti.o for glibc.
      
      Differential Revision: https://reviews.llvm.org/D40248
      
      llvm-svn: 319020
      2809926c
  4. Nov 22, 2017
  5. Nov 13, 2017
  6. Nov 09, 2017
  7. Nov 07, 2017
    • Rui Ueyama's avatar
      Move MIPS-specific code from Symbols.cpp to MIPS.cpp. · 7957b08e
      Rui Ueyama authored
      We have a lot of "if (MIPS)" conditions in lld because the MIPS' ABI
      is different at various places than other arch's ABIs at where it
      don't have to be different, but we at least want to reduce MIPS-ness
      from the regular classes.
      
      llvm-svn: 317525
      7957b08e
  8. Nov 06, 2017
  9. Nov 03, 2017
    • Rui Ueyama's avatar
      Rename SymbolBody -> Symbol · f52496e1
      Rui Ueyama authored
      Now that we have only SymbolBody as the symbol class. So, "SymbolBody"
      is a bit strange name now. This is a mechanical change generated by
      
        perl -i -pe s/SymbolBody/Symbol/g $(git grep -l SymbolBody lld/ELF lld/COFF)
      
      nd clang-format-diff.
      
      Differential Revision: https://reviews.llvm.org/D39459
      
      llvm-svn: 317370
      f52496e1
  10. Oct 27, 2017
    • Peter Smith's avatar
      [ELF] Introduce range extension thunks for ARM · 75030b6d
      Peter Smith authored
      This change adds initial support for range extension thunks. All thunks must
      be created within the first pass so some corner cases are not supported. A
      follow up patch will add support for multiple passes.
      
      With this change the existing tests arm-branch-error.s and
      arm-thumb-branch-error.s now no longer fail with an out of range branch.
      These have been renamed and tests added for the range extension thunk.
      
      Differential Revision: https://reviews.llvm.org/D34691
      
      llvm-svn: 316752
      75030b6d
    • Peter Smith's avatar
      [ELF] Pre-create ThunkSections at Target specific intervals · f0c70f8d
      Peter Smith authored
      When an OutputSection is larger than the branch range for a Target we
      need to place thunks such that they are always in range of their caller,
      and sufficiently spaced to maximise the number of callers that can use
      the thunk. We use the simple heuristic of placing the
      ThunkSection at intervals corresponding to a target specific branch range.
      If the OutputSection is small we put the thunks at the end of the executable
      sections.
      
      Differential Revision: https://reviews.llvm.org/D34689
      
      llvm-svn: 316751
      f0c70f8d
    • Rui Ueyama's avatar
      Remove an unnecessary inheritance. · ed55e6c6
      Rui Ueyama authored
      llvm-svn: 316716
      ed55e6c6
  11. Oct 26, 2017
    • Bob Haarman's avatar
      [lld] unified COFF and ELF error handling on new Common/ErrorHandler · b8a59c8a
      Bob Haarman authored
      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
      b8a59c8a
  12. Oct 24, 2017
  13. Oct 23, 2017
    • Rui Ueyama's avatar
      Add R_PPC_ADDR16_HI relocation support · 8faafa4f
      Rui Ueyama authored
      The support of R_PPC_ADDR16_HI improves ld compatibility and makes
      things on par with RuntimeDyldELF that already implements this
      relocation.
      
      Patch by vit9696.
      
      llvm-svn: 316306
      8faafa4f
  14. Oct 16, 2017
  15. Oct 13, 2017
  16. Oct 12, 2017
    • Rui Ueyama's avatar
      Remove one parameter from Target::getRelExpr. · be85529d
      Rui Ueyama authored
      A section was passed to getRelExpr just to create an error message.
      But if there's an invalid relocation, we would eventually report it
      in relocateOne. So we don't have to pass a section to getRelExpr.
      
      llvm-svn: 315552
      be85529d
    • Rui Ueyama's avatar
      Rewrite comment. · 63e49d48
      Rui Ueyama authored
      llvm-svn: 315548
      63e49d48
    • Rui Ueyama's avatar
      Define RelType to represent relocation types. · 67533a2c
      Rui Ueyama authored
      We were using uint32_t as the type of relocation kind. It has a
      readability issue because what Type really means in `uint32_t Type`
      is not obvious. It could be a section type, a symbol type or a
      relocation type.
      
      Since we do not do any arithemetic operations on relocation types
      (e.g. adding one to R_X86_64_PC32 doesn't make sense), it would be
      more natural if they are represented as enums. Unfortunately, that
      is not doable because relocation type definitions are spread into
      multiple header files.
      
      So I decided to use typedef. This still should be better than the
      plain uint32_t because the intended type is now obvious.
      
      llvm-svn: 315525
      67533a2c
  17. Oct 06, 2017
  18. Oct 03, 2017
  19. Oct 02, 2017
    • Simon Atanasyan's avatar
      [MIPS] Fix PLT entries generation in case of linking regular and microMIPS code · 649e4d32
      Simon Atanasyan authored
      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
      649e4d32
  20. Sep 21, 2017
  21. Sep 19, 2017
  22. Sep 13, 2017
  23. Sep 12, 2017
    • Simon Atanasyan's avatar
      [MIPS] Initial support of microMIPS code linking · 4f70b30d
      Simon Atanasyan authored
      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
      4f70b30d
  24. Sep 07, 2017
  25. Sep 06, 2017
    • Peter Smith's avatar
      [ELF][AArch64] Add alignment checks for the LDST<N>_ABS_LO12_NC relocations · 1d5a0703
      Peter Smith authored
      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
      1d5a0703
  26. Sep 04, 2017
  27. Aug 31, 2017
  28. Aug 28, 2017
  29. Aug 24, 2017
Loading