search for: bfd

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 is currently setup to use the GCC LTO plugin, which produces...

Hi, I'm trying to build clang/LLVM and am hitting a test failure in compiler-rt/test/safestack/lto.c. I believe the issue is that we've configured clang to use ld.bfd as the linker. ld.bfd has plugin support as described here: https://llvm.org/docs/GoldPlugin.html compiler-rt/test/lit.common.cfg isn't set up to know about ld.bfd: elif config.host_os == 'Linux' and is_linux_lto_supported(): config.lto_supported = True config.lto_launch = []...

....o [LD] res_clioriginate.o -> res_clioriginate.so [CC] res_convert.c -> res_convert.o [LD] res_convert.o -> res_convert.so [CC] res_crypto.c -> res_crypto.o [LD] res_crypto.o -> res_crypto.so collect2: ld terminated with signal 11 [Segmentation fault] /usr/bin/ld: BFD 2.17 Debian GNU/Linux assertion fail ../../bfd/elflink.c:2363 /usr/bin/ld: BFD 2.17 Debian GNU/Linux assertion fail ../../bfd/elflink.c:2365 /usr/bin/ld: BFD 2.17 Debian GNU/Linux assertion fail ../../bfd/elflink.c:2366 make[1]: *** [res_crypto.so] Error 1 make: *** [res] Error 2 ------------------...

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.". Does this mean BFD LD after 2.20 can support LLVMgold.so? Ld ver...

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 fre...

...t, 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 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 is currently setup to use > the GCC LTO pl...

Hi I'm using Gluster 3.2.5. After expanding a 2x2 Distributed-Replicate volume to 3x2 and performing a full rebalance fuse clients log the following messages for every directory access: [2012-03-08 10:53:56.953030] I [dht-common.c:524:dht_revalidate_cbk] 1-bfd-dht: mismatching layouts for /linux-3.2.9/tools/power/cpupower/bench [2012-03-08 10:53:56.953065] I [dht-layout.c:682:dht_layout_dir_mismatch] 1-bfd-dht: subvol: bfd-replicate-2; inode layout - 0 - 0; disk layout - 2863311530 - 4294967295 [2012-03-08 10:53:56.953080] I [dht-common.c:524:dht_revalid...

...AM Fangrui Song <maskray at google.com> wrote: >> >> >> >> >> >> Thanks for the write-up! >> >> >> >> >> >> On 2020-07-16, David Blaikie wrote: >> >> >> >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...

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...

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 the future by default I think we're going to need to provide release notes about this and do aggressive outreach towards the consumers we do know before making the change. If anyone wa...

...t; >> >On Fri, Jul 17, 2020 at 12:03 AM Fangrui Song <maskray at google.com> wrote: >> >> >> >> Thanks for the write-up! >> >> >> >> On 2020-07-16, David Blaikie wrote: >> >> >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 f...

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. It can load the same shared objects > > used by gold and uses them to provide basic support for new file formats.”. > Does this mean BFD LD after 2.20 can support LLVMg...

...gt; 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 the future by default I think we're going to need to provide release notes about this and do aggressive outreach towards the consumers we do know before making the change. If anyone wa...

...when eda.so should be made. make[4]: Entering directory `/u/u2/maechler/Linux/R/R-0.64.2/src/library/eda/src' gcc -g -O2 -fpic -I../../../../include -c line.c -o line.o gcc -g -O2 -fpic -I../../../../include -c smooth.c -o smooth.o ld -shared -o eda.so line.o smooth.o ld: bfd assertion fail elf32-i386.c:621 ld: bfd assertion fail elf32-i386.c:1414 make[4]: *** [eda.so] Segmentation fault make[4]: *** Deleting file `eda.so' make[4]: Leaving directory `/u/u2/maechler/Linux/R/R-0.64.2/src/library/eda/src' <.....> make: *** [R] Error 1...

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 -s scp /usr/local/bin/scp BFD: /usr/local/bin/stC4aqIw: warning: allocated section `.interp' not in segment ./install-sh -c -m 0755 -s ssh-add /usr/local/bin/ssh-add BFD: /usr/local/bin/s...

...+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 Mon, Jul 27, 2020 at 9:11 AM Robinson, Paul <paul.robinson at sony.com> wrote: >> >> > 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 fou...

...(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 > 0000000000000000 w *UND* 0000000000000000 hello_world > > $ clang -fuse-ld=bfd -flto=thin -O2 -shared -fPIC -o libmore.so more.c > $ objdump -t libmore.so |grep hello > 0000000000000000 *UND* 0000000000000000 hello_world > Same issue reproduces with just -flto (not just -flto=thin). So this is a general issue with ld.bfd interactions with LLVMgol...

...opt 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 the future by default I think we're going to need to > provide release notes about this and do aggressive outreach towards the > consumers we do know before making the...

> 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,...

...r to upgrade a linker than to upgrade a >debugger. I don't have any strong opinions on what we should name the >command line option, but something that makes it unnecessary to actually >know the values you want to put in would make it easier. >-debug-comdat-relocation-filler=compat, bfd, <something> (yes, that's not >great, but it's at least a start :) > >-eric .debug_* => 0 looks good to me and I'd like to make the change because some users in this thread expressed preference, while some are bystanders, and I don't want to be the only one on the...