search for: linkers

Problem compiling R. version: 0.64.2 machine: SGI O2 OS: IRIX6.5 CC cc FC f77 MAKE GNU make 3.75 Here is part of the the output for make. make[2]: Leaving directory `/usr/people/faculty/math/mgass/stage/R/R-0.64.2/src/include' make[2]: Entering directory `/usr/people/faculty/math/mgass/stage/R/R-0.64.2/src/appl' cc -g -OPT:IEEE_NaN_inf=ON -I../include

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 makes deployment and validation quite cumbersome on GNU systems. I'd like to suggest a change in behaviour: // Some flag like

.... I am particularly interested in any linker script use cases that are prevalent in projects you care about but that do not readily fit the above model. References:  [1] Talk presented at 2017 US LLVM Developers' Meeting, San Jose, CA.      Slides: http://llvm.org/devmtg/2017-10/slides/LTOLinkerScriptsEdlerVonKoch.pdf      Video:  https://youtu.be/hhaPAKUt35E -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

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

...#39;t support in this form can be fatal). > >>> > Starting small is the best way, with `-l` and `-L` as a starting > point. > >>> > I > >>> > want to retain the ability to add additional options which may not be > >>> > available in all linkers. However, whitelisting obviously requires > >>> > working > >>> > with the linker as would adding such options, so that could be > handled > >>> > at > >>> > that time. > >>> > >>> This is actually why I'd p...

Hi all, Which are the command-line options available to pass linker script, library path etc.. to lld? I see minimal options listed, when i say, lld -flavor gnu -help Thanks in advance, -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150209/e7a6f7b8/attachment.html>

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 that, this thread is specifically for the *backend*, we are not discussing how to get the information to the backend here at all, but assuming that the information is present in the same LLVM IR encoding (llvm.linker-options module metadata string). In order to have compatibility with existing linkers, I am suggesting the use of an ELF note. These are implicitly dropped by the linker so we can be certain that the options will not end up in the final binary even if the extension is not supported. The payload would be a 4-byte version identifier (to allow future enhancements) and a null-terminat...

Hi Waxiado, Chris and Tim, when i compiled with : > $ clang++ -g try.cpp `llvm-config --cppflags --ldflags --libs core jit > native`-o3 -S -emit-llvm I get the following warnings > clang: warning: -lz: 'linker' input unused > clang: warning: -lpthread: 'linker' input unused > clang: warning: -lcurses: 'linker' input unused > clang: warning: -lm:

...gt; Starting small is the best way, with `-l` and `-L` as a starting >> >>> > point. >> >>> > I >> >>> > want to retain the ability to add additional options which may not >> >>> > be >> >>> > available in all linkers. However, whitelisting obviously requires >> >>> > working >> >>> > with the linker as would adding such options, so that could be >> >>> > handled >> >>> > at >> >>> > that time. >> >>> >&g...

...and llvm.linker.options implies, at least at first glance, a very open-ended approach. Can you describe how open-ended llvm.linker.options is, in fact/in practice? I.e. what subset of linker options do the COFF/MachO targets actually support? > > In order to have compatibility with existing linkers, I am suggesting the > use of an ELF note. These are implicitly dropped by the linker so we can > be certain that the options will not end up in the final binary even if the > extension is not supported. The payload would be a 4-byte version > identifier (to allow future enhancements)...

...ir projects. I think the overall approach for communication between the linker and code generator sounds reasonable. I've got some questions/comments based on some experience with Arm's proprietary linker, which supports LTO but has a different linker script mechanism than GNU ld compatible linkers. I'm not hugely familiar with the details of LTO at the moment so apologies in advance for any misunderstandings on my part. My understanding from the RFC is: - All global objects in the bitcode file will be assigned a section name. - A linker will communicate the output section of all global...

...f you like, a newer more restrictive mechanism could be introduced, but that would be beyond the scope of this change IMO. Both of those do not have any restrictions AFAIK; and any control of what they permit is from the *frontend* side. > >> In order to have compatibility with existing linkers, I am suggesting the >> use of an ELF note. These are implicitly dropped by the linker so we can >> be certain that the options will not end up in the final binary even if the >> extension is not supported. The payload would be a 4-byte version >> identifier (to allow futu...

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

...n a general way to allow the same source code to work in different environments. I would like to propose that we focus on autolinking exclusively and that we divorce the implementation from the idea of "linker options" which, by nature, would tie source code to the vagaries of particular linkers. I don't see much value in supporting other linker operations so I suggest that the binary representation be a mergable string section (SHF_MERGE, SHF_STRINGS), called .autolink, with custom type SHT_LLVM_AUTOLINK (0x6fff4c04), and SHF_EXCLUDE set (to avoid the contents appearing in the output)...

On Mon, May 04, 2015 at 12:52:55PM -0700, Chris Lattner wrote: > I think the problem here is that these lead to natural and inescapable > tensions, and Alex summarized how Camp B has been steering LLD away > from what Camp A people want. This isn’t bad in and of itself, because > what Camp B wants is clearly and unarguably good for LLVM. However, > it is also not sufficient, and

Hi guys, After working for a long period of time on LLD, I think I found a few things that we should improve in the LLD design for both development ease and runtime performance. I would like to get feedback on this proposal. Thanks! *Problems with the current LLD architecture *The current LLD architecture has, in my opinion, two issues. *The atom model is not the best model for some architectures

...ource code to work in different environments. >> >> I would like to propose that we focus on autolinking exclusively and that >> we divorce the implementation from the idea of "linker options" which, by >> nature, would tie source code to the vagaries of particular linkers. I >> don't see much value in supporting other linker operations so I suggest >> that the binary representation be a mergable string section (SHF_MERGE, >> SHF_STRINGS), called .autolink, with custom type SHT_LLVM_AUTOLINK >> (0x6fff4c04), and SHF_EXCLUDE set (to avoid t...

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

...in the linker space (e.g. a new “native” object file format generated directly from compiler structures) may or may not actually “work” or be “worth it”, we won’t know unless we try, and that won’t fulfill its promise if there are compromises to Camp B. So here’s my counterproposal: two different linkers. Lets stop thinking about lld as one linker, and instead think of it is two different ones. We’ll build a Camp B linker which is the best of breed section based linker. It will support linker scripts and do everything better than any existing section based linker. The first step of this is to d...