similar to: [RFC] Adding a new option to lld to make it easy to maintain compatibility with other linkers

I believe this will report an error on more command-lines than a traditional linker would fail to link. E.g.: ld.lld foo.o A.a B.a A.a B.a That "should" work fine if the libs are circularly-dependent, as long as there's only a 1-level cycle. I've seen that sort of construct used a fair amount, and while the start-group/end-group flags are pretty clearly a superior option, but

On Wed, Apr 4, 2018 at 7:30 PM James Y Knight <jyknight at google.com> wrote: > I believe this will report an error on more command-lines than a > traditional linker would fail to link. E.g.: > ld.lld foo.o A.a B.a A.a B.a > That "should" work fine if the libs are circularly-dependent, as long as > there's only a 1-level cycle. I've seen that sort of

On Thu, Apr 5, 2018 at 12:20 PM Rui Ueyama <ruiu at google.com> wrote: > On Wed, Apr 4, 2018 at 7:30 PM James Y Knight <jyknight at google.com> wrote: > >> I believe this will report an error on more command-lines than a >> traditional linker would fail to link. E.g.: >> ld.lld foo.o A.a B.a A.a B.a >> That "should" work fine if the libs are

On Thu, Apr 5, 2018 at 10:51 AM James Y Knight <jyknight at google.com> wrote: > > > > On Thu, Apr 5, 2018 at 12:20 PM Rui Ueyama <ruiu at google.com> wrote: > >> On Wed, Apr 4, 2018 at 7:30 PM James Y Knight <jyknight at google.com> >> wrote: >> >>> I believe this will report an error on more command-lines than a >>>

On Mon, Aug 31, 2020 at 1:29 PM David Blaikie <dblaikie at gmail.com> wrote: > > > > On Mon, Aug 31, 2020 at 1:24 PM Fāng-ruì Sòng <maskray at google.com> wrote: >> >> On Fri, Aug 28, 2020 at 11:16 AM David Blaikie <dblaikie at gmail.com> wrote: >> > >> > Would you like to conduct the conversation here, or on the review thread? (I lean

On 2020-09-01, Petr Hosek wrote: >I see the GNU ld behavior as a limitation, not as a feature, as Peter Smith >also pointed out in https://reviews.llvm.org/D86762. While it can be argued >that there are certain cases where it can help detect layering >violations as you mentioned in your change, I'm not sure how valuable that >is in practice. Every case I've encountered so

On Fri, Aug 28, 2020 at 11:16 AM David Blaikie <dblaikie at gmail.com> wrote: > > Would you like to conduct the conversation here, or on the review thread? (I lean towards having them here, but don't mind if folks feel like it keeps the noise down & want to more post a notice saying "hey, here's this thing, if you're interested, go discuss it over there" -

Can you link to docs about the wasm object format? (both relocatable and executable) Also, traditional object file linkers are primarily concerned with concatenating binary blobs with small amount of patching of said binary blobs based on computed virtual (memory) addresses. Or perhaps to put it another way, what traditional object file linkers do is construct program images meant to be mapped

Hi Sam, First, I want to know the symbol resolution semantics. I can imagine that that is set in stone yet, but just that you guys are still discussing what would be the best semantics or file format for the linkable wasm object file. I think by knowing more about the format and semantics, we can give you guys valuable feedback, as we've been actively working on the linker for a few years

On Thu, Sep 3, 2020 at 5:15 PM Nico Weber <thakis at chromium.org> wrote: > I wanted to chime in and say that I think we should keep the current > default too, for three reasons: > > 1. The current default is more user friendly. Users shouldn't have to > worry about if they pass -lpthread before or after their .o files (...or > other libraries. I know I know for

On 2020-09-03, Peter Collingbourne wrote: >On Thu, Sep 3, 2020 at 2:00 PM Fāng-ruì Sòng <maskray at google.com> wrote: > >> On 2020-09-03, Peter Collingbourne wrote: >> >On Tue, Sep 1, 2020 at 5:35 PM Fāng-ruì Sòng via llvm-dev < >> >llvm-dev at lists.llvm.org> wrote: >> > >> >> On 2020-09-01, Petr Hosek wrote: >> >> >I

It looks like the conversation has died, but I just wanted to post my own investigation based on our internal code base. The code base itself is quite a sprawling mass, involving multiple different build systems, some bits CMake based, some hand-curated and so on, and I don't fully comprehend it all. I do know that trying to change it is hard at best, and more likely impossible to do so

On 2020-09-03, Peter Collingbourne wrote: >On Tue, Sep 1, 2020 at 5:35 PM Fāng-ruì Sòng via llvm-dev < >llvm-dev at lists.llvm.org> wrote: > >> On 2020-09-01, Petr Hosek wrote: >> >I see the GNU ld behavior as a limitation, not as a feature, as Peter >> Smith >> >also pointed out in https://reviews.llvm.org/D86762. While it can be >> argued

On Sat, Dec 16, 2017 at 11:40 AM George Rimar <grimar at accesssoftek.com> wrote: > Or following workflow: > > Split dwarf is used to make linker to proccess less, like relocations, > right ? > Partly, though the main motivation as far as I know, was to have to provide fewer bytes to the linker at all. That's why something like Apple's scheme (leave the debug info in

Hi llvmers, As you may know, work has been progressing on the experimental WebAssembly backend in llvm. However, there is currently not a good linking story. Most the of existing linking strategies (i.e. those in the emscripten toolchain) involve bitcode linking and whole program compilation at link time. To improve this situation I've been working on adding a wasm backend for lld. My

Hi all, LLD's --warn-backrefs is a tool to identify potential incompatible archive selection semantics with traditional Unix linkers. I have improved it (via D77522,D77630 and D77512) to a state where a --warn-backrefs diagnostic almost assuredly means that the link will fail with GNU ld, or the symbol will get different resolution in GNU ld and LLD. My conclusion is that --warn-backrefs is a

We're in the process of importing lld into FreeBSD (along with our Clang 3.9 update project). For now I've removed all but the ELF linker[1]. We have no need for COFF and Mach-O, and we have a bespoke build system for all of our contrib code. I didn't bother adding build support for the source files for non-ELF linkers. Is this something that'd be reasonable / desirable to have

On Tue, Dec 13, 2016 at 9:15 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > ------------------------------ > > *From: *"Sean Silva via llvm-dev" <llvm-dev at lists.llvm.org> > *To: *"Rui Ueyama" <ruiu at google.com> > *Cc: *"llvm-dev" <llvm-dev at lists.llvm.org> > *Sent: *Tuesday, December 13, 2016 9:59:37 PM >

On Tue, Dec 13, 2016 at 12:01 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Dec 13, 2016, at 11:51 AM, Rui Ueyama <ruiu at google.com> wrote: > > On Tue, Dec 13, 2016 at 11:37 AM, Mehdi Amini <mehdi.amini at apple.com> > wrote: > >> >> On Dec 13, 2016, at 11:30 AM, Rui Ueyama <ruiu at google.com> wrote: >> >> On Tue, Dec

?But could not we for example do split dwarf, but for example do dedup of types ? I do not mean right now, but in a theory ? Best regards, George | Developer | Access Softek, Inc ________________________________ От: David Blaikie <dblaikie at gmail.com> Отправлено: 16 декабря 2017 г. 22:25 Кому: George Rimar Копия: Sean Silva; llvm-dev at lists.llvm.org; Rui Ueyama; Rafael Espindola Тема: