similar to: Failing compiler-rt LTO test

Rafael, Rui, This is obviously an old thread, but in case there is interest, I've been able to get this to work (using the LLVM gold plugin with the ld.bfd linker). This requires some additional logic in the ld.bfd linker (and a small change to the bfd library). I've attached the patch (against binutils HEAD from 2013-09-17) in case anyone finds this useful. The core issue is that ld.bfd

Hi, i tried to compile Asterisk 1.4.21.2 on a server which i have been using with many previous Asterisk versions, without any problems. But with 1.4.21.2 it failed: ---------------------------------- [CC] res_adsi.c -> res_adsi.o [LD] res_adsi.o -> res_adsi.so [CC] res_agi.c -> res_agi.o [LD] res_agi.o -> res_agi.so [CC] res_clioriginate.c -> res_clioriginate.o

Hi, I am trying to use LLVM LTO. I read http://llvm.org/docs/GoldPlugin.html and have some questions. Could anyone help? 1. Can LLVMgold.so work with BFD LD instead of gold? In the description of changes in binutils 2.20, "* The plugin target has been added to bfd. It can load the same shared objects used by gold and uses them to provide basic support for new file formats.".

On 28 October 2016 at 17:41, Hans Wennborg <hans at chromium.org> wrote: > There's also -fuse-ld= > > That's how I usually do it. Right, that gets rid of the override flag. Thanks! :) But the arguments about the default and the cross-compilation error still stand. cheers, --renato

Quick update: the previous patch only worked for static linking; this version should work for both static and dynamic linking. I'm not going to send any more updated patches to this list, but please feel free to e-mail me off-list, and I'll be happy to share any updates I have at any point in the future. -Hal ----- Original Message ----- > Rafael, Rui, > > This is obviously

On 1 August 2012 23:00, Sun, Rui <rui.sun at intel.com> wrote: > Hi, > > > > I am trying to use LLVM LTO. I read http://llvm.org/docs/GoldPlugin.html and > have some questions. Could anyone help? > > > > 1. Can LLVMgold.so work with BFD LD instead of gold? In the > description of changes in binutils 2.20, “* The plugin target has been added > to bfd.

GCC LTO works ok for the test case with both bfd and gold linker. David On Tue, Oct 4, 2016 at 6:58 AM, Teresa Johnson <tejohnson at google.com> wrote: > > > On Mon, Oct 3, 2016 at 6:15 PM, Teresa Johnson <tejohnson at google.com> > wrote: > >> >> >> On Mon, Oct 3, 2016 at 5:24 PM, Xinliang David Li <xinliangli at gmail.com> >> wrote:

On Mon, Oct 3, 2016 at 5:24 PM, Xinliang David Li <xinliangli at gmail.com> wrote: > Small repro: > > __attribute__((weak)) int hello_world(); > > int test() { > if (hello_world) > return hello_world(); > return 0; > } > > $ clang -fuse-ld=gold -flto=thin -O2 -shared -fPIC -o libmore.so more.c > $ objdump -t libmore.so |grep hello >

You should probably send them for review/inclusion in bfd. On 11 October 2013 12:39, Hal Finkel <hfinkel at anl.gov> wrote: > Quick update: the previous patch only worked for static linking; this version should work for both static and dynamic linking. > > I'm not going to send any more updated patches to this list, but please feel free to e-mail me off-list, and I'll be

>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 12:03 AM Fangrui Song <maskray at google.com> wrote: >> >> >> >> Thanks for the write-up! >> >> >>

>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-29, Eric Christopher wrote: >I think the arguments are largely compatibility for software that's already >deployed and can't easily upgrade, and wanting to ensure a larger time >frame for migration with a fallback if things go wrong. A bridge basically >from what we had to where we'd like to be. > >I think we also need to make the change in mainline lld as

> My understanding in the past is that we didn't officially support > using the llvm gold plugin with ld.bfd. We don't have any bots that > test that combination (which is why you see the code below in > lit.common.cfg). In my mind, that means using the llvm gold plugin > with ld.bfd is at your own risk (and therefore I would like to remove > the wording around using

On 28 October 2016 at 16:54, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On 28 October 2016 at 17:41, Hans Wennborg <hans at chromium.org> wrote: >> There's also -fuse-ld= >> >> That's how I usually do it. > > Right, that gets rid of the override flag. Thanks! :) > > But the arguments about the default and the

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

Created https://reviews.llvm.org/D84825 to be used for release/11.x I haven't seen a strong argument for changing other .debug_* but in any case I don't want to continue debating on this topic. * .debug_ranges & .debug_loc: -2 (lld<11: 0+addend) * .debug_*: 0 (lld<11: 0+addend, lld HEAD: -1) On Mon, Jul 27, 2020 at 12:47 PM David Blaikie <dblaikie at gmail.com> wrote:

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,

>From my understanding the breakpad bug was also only related to .debug_line and has been fixed by https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2317730 > a) .debug_ranges&.debug_loc => -2, .debug_line => 0, other .debug_* -> -1 > b) .debug_ranges&.debug_loc => -2, other .debug_* => 0 I am still of the opinion that we should just do a), not b).

Hello, System info: Sparcstation 5, Solaris 2.7, openssl-0.9.8i. I've tried to install openssh-3.9p1 openssh-4.9p1 openssh-5.1p1 all failed the similar way. The following is the last portion of the 'make install' printout. ./install-sh -c -m 0755 -s ssh /usr/local/bin/ssh BFD: /usr/local/bin/stkuaiGw: warning: allocated section `.interp' not in segment ./install-sh -c -m 0755

> I still think that we do bfd locs with a decent option to change for at least the current release and sources and then, once we're a little more certain we have everything that might want to parse dwarf (say by working with dwarf-discuss), we can change the default. Given what’s been found, I think Eric/Dave are correct, use bfd behavior by default with an option to do the new thing.