similar to: Linking the FreeBSD base system with lld -- status update

Hello, I am currently switching to ldd from ld.bfd on a cross-platform embedded project and am facing a behaviour difference when using the same linker scripts with ld.bfd and ldd. Could anybody please give me a more reliable direction I should go with to get the same behaviour from both of the linkers? Target binary format is a 32-bit ELF executable, which is expected to consist of a single RWX

One of the issues I reported in using lld as the FreeBSD base system linker is that the base system currently uses ld -r to convert a binary file (device firmware image) into an ELF object: > A tool for loading firmware into a wireless USB device includes a > built-in copy of the firmware image, and the image is converted to an > ELF file using ld -r. The invocation is: ld -b binary -d

Hi all! Yesterday I upgraded to FreeBSD 10.0-RC1 through freebsd-update. Everything seemed fine until I decided to upgrade my ports today. There was a new version of pkg which built fine up until the linking: ===> Building for pkg-1.2.3 --- all --- ===> libpkg (all) --- objwarn --- --- libpkg.so.1 --- --- objwarn --- Warning: Object directory not changed from original

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

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

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

>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

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:

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

On 28 October 2016 at 18:12, Ed Maste <emaste at freebsd.org> wrote: > It should be possible to search the path for ld.lld first, then ld, > but to me it seems like it will just be more confusing. Hum, for me it would be less confusing. :) GCC uses bfd by default, LLVM uses LLD. If you want to change, use -fuse-ld. What would be confusing in this scenario? > Clang's current

As I mentioned in the thread (to many people who don't have time to read the discussions), pushing https://reviews.llvm.org/D84825 restores the original behavior. The same effect as one would get by reverting all related patches. If someone gives me an approval, I'll push it immediately. I already get verbal LGTM from Peter. > With respect I think the "request for changes"

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

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,

I've noticed that lld keeps the data section more isolated than the gold or bfd linkers. For example, readelf -l applied to the "same" executable linked with those three linkers reveals the following under "Section to Segment mapping": lld: 05 .data .got.plt .bss gold: 03 .eh_frame .init_array .fini_array .preinit_array .dynamic .got .got.plt .data .bss bfd: 05

Can we please just revert back to what we had before until the discussion about the desired behaviour and how to get there reaches a conclusion? In particular, I would like to merge that revert to the 11.x branch. At this point in the release process, I'm not keen on taking any patch that changes the behavior to something that hasn't been well tested from sitting in trunk for a while. On

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

> 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

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

>Пятница, 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 2020-07-16, David Blaikie wrote: >> >In short: Perhaps we should switch lld to the bfd-style tombstoning >> >behavior for a release or