similar to: ld.gold --verbose

Hi While cross compiling on Mac Host: Mac Target: Linux on ArmV7 How can I force clang to use the non-system linker But use llvm-lld (i.e. ld.lld) or any other non standard linker Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180326/d86e1601/attachment.html>

The option -fuse-ld is the closest option that I can think of. In its most common form it accepts bfd, gold or lld, clang will then invoke ld.bfd, ld.gold or ld.lld respectively. On many systems ld is a symlink to an executable of the form ld.suffix. Alternatively the full path to the linker can be given -fuse-ld=/full/path/to/linker/executable Peter On 27 March 2018 at 00:40, Sumonto Ghosh via

Hi, Is there a way to retrieve the start/end of .text section (at runtime) without having to add additional PROVIDE() variables to the linker script? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180508/db4636fc/attachment.html>

Hi, unfortunately, my build somehow hangs when linking clang binary and my system is in an unusable state. My toolchain is clang-3.8, gold-1.11 and LLVMgold.so from binutils v2.26.1 (both selfmade) and LTO-flag is enabled. My buildsystem uses cmake-3.6.0 and ninja-1.7.1 (both prebuilt). I have 52 last steps left in my 3rd build. My Linux-kernel is v3.13.0-92 from official Ubuntu repositories.

Is there a regression bot with a list of tests or alike Thanks On Mon, Feb 26, 2018 at 4:19 PM Rafael Avila de Espindola < rafael.espindola at gmail.com> wrote: > I think ARM ELF is pretty good. I was able to link clang with it some > time ago and it now has support for thunks. > > Cheers, > Rafael > > > Sumonto Ghosh <sumonto.ghosh at gmail.com> writes: >

How big is your project? LTO eats RAM even faster than chrome. For example linking clang with LTO could take 16GB of ram. Have you tried using LTO on your project on that machine, or is it your first time? Piotr On Sat, Jul 23, 2016 at 2:42 AM, Sedat Dilek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Jul 21, 2016 at 12:01 PM, Sedat Dilek <sedat.dilek at

Dear all, I'm trying to use the gold plugin to make it easier to generate LLVM bitcode from complex applications. I did the steps mentioned on "http://llvm.org/docs/GoldPlugin.html". Both linking and LLVM generation seem to work properly, however when using the tool ar, the symbol table is lost. "no archive symbol table (run ranlib)". I'm using LLVM 2.9, Ubuntu 10.10,

Hi all, I got an error from the gold plugin example in the following link: http://llvm.org/docs/GoldPlugin.html#example1 Here is the error message: sangmin at sangmin-desktop:/tmp$ llvm-gcc -use-gold-plugin a.a b.o -o main /usr/bin/ld: error: a.a: no archive symbol table (run ranlib) /usr/bin/ld: /usr/lib/crt1.o:(.text+0x18): error: undefined reference to 'main' /usr/bin/ld: b.o: in

> On Jul 23, 2016, at 1:53 PM, Sedat Dilek via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > On Sat, Jul 23, 2016 at 7:48 PM, Piotr Padlewski <prazek at google.com <mailto:prazek at google.com>> wrote: >> How big is your project? >> LTO eats RAM even faster than chrome. For example linking clang with LTO >>

I have been trying to enable the gold linker on FreeBSD to use the link time optimizations. I made gold from the binutils under /usr/ports. After building binutils using make -k install clean i got ld under /usr/bin and in the directory /usr/local/bin i got ld, ld.gold and ld.bfd. Now while trying to use link time optimization for the simple example programs

the symlink ld is already pointing to /usr/bin/ld. Also -fuse-ld=gold does not works on clang in freebsd. I am not sure where is the problem?should I remove /usr/bin/ld and create a new symlink to /usr/local/bin/ld.gold? Regards Aditya Verma Junior Undergraduate IDD Computer Sc & Engg IIT(BHU), Varanasi(UP) On Mon, Jun 22, 2015 at 5:25 AM, Rafael Espíndola < rafael.espindola at

Hi, I fixed error by using different version of ld with LLVM 2.7. I used ld.gold that comes with Ubuntu 10.04. Here is the version info: sangmin at sangmin-desktop:/tmp$ ld -v GNU gold (GNU Binutils for Ubuntu 2.20.1-system.20100303) 1.9 My experience of gold plugin is as follows: LLVM 2.7 (with libLLVMgold.so) + ld 2.20.1 (from Ubuntu 10.04) : O LLVM 2.7 (with libLLVMgold.so) + ld 2.21.51

Thanks Rafael, wondering as of what is the level of support for ARM and is it close to production quality? Thanks On Mon, Feb 26, 2018 at 2:06 PM, Rafael Avila de Espindola < rafael.espindola at gmail.com> wrote: > Not sure there is an official POC, you are probably better off asking > whatever question you have directly on the list. > > Cheers, > Rafael > > Sumonto

Hi all, I tried to build the LLVMgold plugin. Something weird happened. Here is the error message: gold-plugin.cpp:45: error: âld_plugin_set_extra_library_pathâ does not name a type gold-plugin.cpp: In function âld_plugin_status onload(ld_plugin_tv*)â: gold-plugin.cpp:141: error: âLDPT_OUTPUT_NAMEâ was not declared in this scope gold-plugin.cpp:199: error: âLDPT_SET_EXTRA_LIBRARY_PATHâ was

On 11-03-21 10:35 PM, Sangmin Park wrote: > Hi, > > I fixed error by using different version of ld with LLVM 2.7. > I used ld.gold that comes with Ubuntu 10.04. > Here is the version info: > > sangmin at sangmin-desktop:/tmp$ ld -v > GNU gold (GNU Binutils for Ubuntu 2.20.1-system.20100303) 1.9 > > My experience of gold plugin is as follows: > > LLVM 2.7 (with

I think ARM ELF is pretty good. I was able to link clang with it some time ago and it now has support for thunks. Cheers, Rafael Sumonto Ghosh <sumonto.ghosh at gmail.com> writes: > Thanks Rafael, wondering as of what is the level of support for ARM and is > it close to production quality? > > Thanks > > On Mon, Feb 26, 2018 at 2:06 PM, Rafael Avila de Espindola <

Hi All, In general I think we should adopt Dave's plan here. The number of consumers that can (and have) been caught off guard by this change is just too high. At the very least I think we should move this to opt in to the new tombstoning behavior by default and at most migrate to bfd's behavior for both the current release and in the current tree. If we want to make this sort of change

In short: Perhaps we should switch lld to the bfd-style tombstoning behavior for a release or two, letting users opt-in to testing with the new -1/-2 tombstoning in the interim, before switching to the new tombstone by default (while still having the flag to switch back when users find surprise places that can't handle the new behavior). In long: https://reviews.llvm.org/D81784 and follow-on

>On Mon, Jul 20, 2020 at 10:32 AM Alexey Lapshin ><alapshin at accesssoftek.com> wrote: >> >> >On Fri, Jul 17, 2020 at 1:55 PM Alexey Lapshin <a.v.lapshin at mail.ru> wrote: >> >> >> >> >Пятница, 17 июля 2020, 19:42 +03:00 от David Blaikie <dblaikie at gmail.com>: >> >> > >> >> >On Fri, Jul 17, 2020 at

On 2020-07-24, Hans Wennborg via llvm-dev wrote: >Sounds good to me from a release perspective. I think we need more input from the triage of https://chromium-review.googlesource.com/c/chromium/src/+/2291352 whether it is just .debug_line or .debug_* >On Fri, Jul 24, 2020 at 7:53 AM Eric Christopher via llvm-dev ><llvm-dev at lists.llvm.org> wrote: >> >> Hi All,