Announcement

Collapse
No announcement yet.

LLVM Is Developing A New ELF Linker

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • LLVM Is Developing A New ELF Linker

    Phoronix: LLVM Is Developing A New ELF Linker

    The LLVM project has announced they've developed a new ELF linker by rewriting the ELF support within LLVM's LLD...

    http://www.phoronix.com/scan.php?pag...New-ELF-Linker

  • #2
    The LLVM ecosystem is growing, indeed.
    IIRC, there's only an assembler missing in order for LLVM to provide a full stack for compiler designers (mainly Clang)

    Comment


    • #3
      Its a godsend for anyone interested in Compilers. For production and embedded you still rely on binutils, and I doubt the linker will get full compatibility with ld for some years.
      ld and its scripts are obese with hidden functionality and special conditions.

      An a second thought a clean new script desing would probably be a more worthwhile target

      Comment


      • #4
        Gold still isn't fully compatible to bfd, and the llvm-developers claim to reach this goai?

        Comment


        • #5
          Originally posted by elmerovingio View Post
          IIRC, there's only an assembler missing in order for LLVM to provide a full stack for compiler designers (mainly Clang)
          Clang has its own built-in assembler. Just compile with the "-xassembler option" (or create a symlink from clang, named as) to use it as a stand-alone (and command-line comaptible) GNU as replacement.

          Originally posted by PuckPoltergeist View Post
          Gold still isn't fully compatible to bfd, and the llvm-developers claim to reach this goai?
          No, they don't. Instead they say "lld is not at feature parity with gold yet"

          Comment


          • #6
            Originally posted by PuckPoltergeist View Post
            Gold still isn't fully compatible to bfd,
            Do you have an example? Sometimes the difference is intentionally. For example, -Y on gold acts differently than bfd, on purpose. The man page of ld.bfd says -Y is meant for compatibility with Solaris, yet acts differently than solaris. Gold matches the Solaris implementation as advertised. Technical that means gold is "not compatible" with ld.bfd, and it never will be by that measure. Your quote implies ld.bfd does everything correctly and thus is the standard from which everything else should be measured, but I might debate that.

            Comment


            • #7
              So what else is needed to make LLVM/Clang completely binutils-independent? if as (clang) and ld (lld) are there. If I remember correctly there are already ranlib and objcopy alternatives in LLVM?

              Comment


              • #8
                Originally posted by Pacific Rim View Post

                Do you have an example?
                I have some:
                -warn-once
                --hash-size
                --default-symver
                and other problems tracked here, including stuff that builds but doesn't work properly.

                Comment


                • #9
                  Originally posted by Ansla View Post
                  I have some:
                  -warn-once
                  --hash-size
                  --default-symver
                  and other problems tracked here, including stuff that builds but doesn't work properly.
                  Okay, thanks but lets look at these:

                  --warn-once: This looks current, but it is a warning flag. There are plenty of gcc warning flags that clang still doesn't recognize. The point is, this is not a performance thing, something that affects it's ability to link. Failure to be compatible with ld.bfd is true, but weak
                  --hash-size: this seems like the original issue is that ghc configure didn't test for supported linker options. I see reports going back 5 years. It looks like hash-size is implementation specific, e.g. performance tuning. I don't know fair ld-specific performance tuning against gold
                  --default-symver: this might be legitimate: https://sourceware.org/bugzilla/show_bug.cgi?id=15910

                  I would be interested to know the true impacts of the last one (e.g. why does software "require" it and why can't standard symbol maps be used instead).

                  Comment

                  Working...
                  X