similar to: LLD to be the default linker in Clang

On Fri, Oct 28, 2016 at 9:17 AM, Renato Golin via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Folks, > > I'm creating a bootstrap buildbot on AArch64 with LLD and I just > realised the "accepted" way to make clang call lld is to "symlink lld > -> ld". I understand that's how every Linux system "chooses" the > linker, but that

On Fri, Oct 28, 2016 at 9:17 AM, Renato Golin via cfe-dev <cfe-dev at lists.llvm.org> wrote: > I'm creating a bootstrap buildbot on AArch64 with LLD and I just > realised the "accepted" way to make clang call lld is to "symlink lld > -> ld". I understand that's how every Linux system "chooses" the > linker, but that makes deployment and

On Sat, Oct 29, 2016 at 5:43 PM, Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On Fri, Oct 28, 2016 at 9:17 AM, Renato Golin via cfe-dev > <cfe-dev at lists.llvm.org> wrote: >> >> Folks, >> >> I'm creating a bootstrap buildbot on AArch64 with LLD and I just >> realised the "accepted" way to make clang call lld

I did not realize LLD was already far enough along to use. I have a related question: What about using LLD via library API? I would love to link against LLD and call API functions instead of trying to find the system linker and spawning a child process and having different code for each system linker. If I could use LLD as a library that would be one less moving part in my compiler, one less

Hello Renato, Thanks very much for raising the topic. I've not got much to add to what has already been said. If I understand correctly there are two use cases that we would want to consider separately: - Using lld by default when clang is used on a platform such as linux if it is installed. - Using lld by default in build-bots and the llvm test-suite when it is installed. For the former,

Hi, I stopped into IRC to ask about a problem I've been having using Clang in conjunction with LLD to compile and link for an embedded project on Cortex-M ARM processor. First, I am able to separately compile with a call to clang and link with a call to lld, but I cannot use clang to link using lld using the -fuse-ld=lld flag. I have the output from `clang -v -fuse-ld=lld -target

I build llvm/clang/lld from source on Windows using mingw-64/gcc-6.3. I use clang++ both to test clang targeting gcc and clang targeting VC++. When using clang targeting VC++ I use the appropriate target triple when compiling and am trying to use lld to link the object file(s) into an exe. To do that I use the clang option "-fuse-ld=lld" when linking. According to the llvm doc on

On 22 August 2018 at 04:27, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > However, if you pass the -emit-relocs option to the linker, lld keeps all > relocations that have already been resolved in an output executable. By > analyzing a relocation table in a resulting executable, you could find all > locations where the ifunc PLT is called. Then, you can

On Sat, Mar 19, 2016 at 9:51 PM, James Molloy via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Lorenzo, > > Clang doesn't call llc; LLVM is compiled into Clang. Clang does call the > system linker though. > > Making your compiler generate *object* code is very simple. Making it > fixup that object code and execute it in memory (JIT style) is also simple. >

> On Apr 9, 2018, at 3:23 PM, James Y Knight via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > I'm not really clear on the actual benefits of the TBD file, and why Apple migrated to them in the first place. Shouldn't a dynamic library containing only the relevant parts (e.g. the dynamic symbol table) be roughly comparable in size? And, much simpler to support? I assume

On Mon, Mar 21, 2016 at 8:04 PM, James Molloy <james at jamesmolloy.co.uk> wrote: > > A corrupted file could cause a fatal error or SEGV. > > Uhhh, that's not particularly useful. > "Corrupted" means really corrupted, like ELF header is broken. Is this really the case? > On Mon, 21 Mar 2016 at 19:02 Rui Ueyama <ruiu at google.com> wrote: >

I'd like to make my compiler independent, just like Clang. Doesn't Clang call llc and then system's ld by itself? I don't want my compiler to depend by any other program. I guess there will be a class in the llvm library that generates the object files based on the system's triple and data layout, and then call the system's ld? > On Mar 19, 2016, at 11:48 AM, Bruce

On Jun 16, 2012, at 3:51 PM, Chris Lattner wrote: > On Jun 15, 2012, at 3:48 PM, Nick Kledzik wrote: > >> In lld we have a Reader class which is a factory that takes .o file(s) and produces an in memory lld::File object(s). But in doing so, there could be I/O errors (file not readable) or file may be malformed. We are also using C++11 in lld, so we use std::unique_ptr for managing

Hi Sean On Sun, Feb 26, 2017 at 5:10 AM, Sean Silva <chisophugis at gmail.com> wrote: > > For that triple, Clang seems to be calling into GCC driver > (/usr/bin/arm-none-eabi-gcc) for linking and GCC doesn't recognize > -fuse-ld=lld (supposedly -fuse-ld=gold selects ld.gold, -fuse-ld=bfd > selects ld.bfd and you would expect -fuse-lld=lld to select ld.lld, but it >

On 2020-09-03, Peter Collingbourne wrote: >On Tue, Sep 1, 2020 at 5:35 PM Fāng-ruì Sòng via llvm-dev < >llvm-dev at lists.llvm.org> wrote: > >> On 2020-09-01, Petr Hosek wrote: >> >I see the GNU ld behavior as a limitation, not as a feature, as Peter >> Smith >> >also pointed out in https://reviews.llvm.org/D86762. While it can be >> argued

Hi Jack, Are you packaging all the static libraries that lld produces as part of the package ? PS : When I build on x86_64, I only get a 9M image for lld. Thanks Shankar Easwaran On 11/20/2013 9:15 AM, Jack Howarth wrote: > When lld-3.4 is added to the tools directory of the llvm source tree > as lld, the resulting cmake build produces a huge number of static libs and > bloats

I believe what's happening here is that clang translates the -fuse-ld=lld into calling the ld.lld executable, which is actually the ELF LLD linker, not the Mach-O one. On 6.0, the Mach-O linker symlink is called ld64.lld instead (and clang has been changed to call out to that name) to disambiguate the two. For 5.0, I'm not sure how best to force the Mach-O linker (I'm not familiar with

Hi. I'm using LLVM 5.0.1 on macOS 10.12. I have a very simple program (program.c): int main() {} When attempting to compile with LLD, I get this output: $ clang -fuse-ld=lld program.c /opt/llvm/5.0.1/bin/ld.lld: error: unknown argument: -no_deduplicate /opt/llvm/5.0.1/bin/ld.lld: error: unknown argument: -dynamic /opt/llvm/5.0.1/bin/ld.lld: error: unknown argument: -arch

When lld-3.4 is added to the tools directory of the llvm source tree as lld, the resulting cmake build produces a huge number of static libs and bloats the overall package from... -rw-r--r-- 1 root wheel 86361440 Nov 19 21:09 llvm34_3.4-0_darwin-x86_64.deb to -rw-r--r-- 1 root wheel 495257452 Nov 19 20:49 llvm34_3.4-0_darwin-x86_64.deb Is this a known issue with the initial release of

On 2020-09-03, Peter Collingbourne wrote: >On Thu, Sep 3, 2020 at 2:00 PM Fāng-ruì Sòng <maskray at google.com> wrote: > >> On 2020-09-03, Peter Collingbourne wrote: >> >On Tue, Sep 1, 2020 at 5:35 PM Fāng-ruì Sòng via llvm-dev < >> >llvm-dev at lists.llvm.org> wrote: >> > >> >> On 2020-09-01, Petr Hosek wrote: >> >> >I