similar to: [LLVMdev] LLD use cases and design meeting and discussion

David, I started a discussion yesterday on lld / chunks for ELF as we need relocations to be read when reading the inputs especially for handling comdat. The other way thus can be done is doing symbol resolution while reading which makes the linker less suitable for concurrent operations. Let me know what you think? Shankar Easwaran > On Jun 5, 2015, at 23:35, Davide Italiano <davide

On Wed, Jan 9, 2013 at 9:13 AM, <shankare at codeaurora.org> wrote: > I dont think any other format has the functionality of sections and > segments with segment and section permissions etc. > > Are you planning to mimic 1-1 lld to ld linker script functionality ? No, there's lots of arcane things that GNU ld has (like compatibility with a completely different linker script

On Wed, Nov 15, 2017 at 10:45 PM, N <scandium at me.com> wrote: > > You can't really remove any native linker-compatible command line > interface unless you get agreement from all parties including Microsoft and > Apple to switch to the GNU command line as the universal interface in the > future versions of their toolchains. > > I completely agree; that's why I

I'm sorry if my suggestion gave an impression that I disregard the Mach-O port of the LLD linker. I do care about Mach-O. I do not plan to break or remove any functionality from the current Mach-O port of the LLD. I don't propose to remove the atom model from the linker as long as it seems to be a good fit for the port (and looks like it is). As to the proposal to have two different

On Thu, May 7, 2015 at 12:58 PM, Jim Grosbach <grosbach at apple.com> wrote: > Hi Rui, > > Thank you for clarifying. This is very helpful. > > It’s unfortunate that you’re not seeing benefits from the increased > semantic knowledge the atom based model can provide. I know you’ve explored > the issue thoroughly, though, so I understand why you’re wanting to move a >

On Jan 9, 2013, at 12:29 PM, Sean Silva wrote: >> Maybe the first version could be just ELF centric. > > The consensus in this thread seems to be that it should be in the > frontend. Nick pointed out that since linker scripts can define > symbols, they need to be handled before the writer; I don't see any > way to avoid that. Could you elaborate on the concrete reasons

Sorry for being late on this thread. I just wanted to say I am strongly on Rui's side on this one. There current design is for lld *not* not be a library and I think that is important. That has saved us a tremendous amount of work for doing library like code and a lot of design for library interfaces. The comparison of old and new ELF code is night and day as far as productivity and

On Mon, Nov 13, 2017 at 9:31 PM, N <scandium at me.com> wrote: > > For example, MSVC link.exe doesn't have --start-group and --end-group > options because their symbol resolution semantics are different than Unix. > > Yes, but this is specific for a linker, not for a target. For example, GNU > ld supports this option for all binary formats. A linker with universal CLI

I'm sorry for not updating the thread -- I thought I did that before. I started experimenting the idea by implementing a minimal linker using the section-based design with some additional simplification/optimizations. It's already able to link small programs like the LLD itself, and the performance looks indeed better (probably the LLD is too small as a benchmark, but the new one is more

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

Hi guys, After working for a long period of time on LLD, I think I found a few things that we should improve in the LLD design for both development ease and runtime performance. I would like to get feedback on this proposal. Thanks! *Problems with the current LLD architecture *The current LLD architecture has, in my opinion, two issues. *The atom model is not the best model for some architectures

On Fri, May 29, 2015 at 8:29 PM, James Y Knight <jyknight at google.com> wrote: > > On May 29, 2015, at 10:08 PM, Rui Ueyama <ruiu at google.com> wrote: > > Large part of the difficulties in development of the current LLD comes > from over-generalizataion to share code between pretty much different file > formats. > > ISTM the problem that's been described

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 Mon, Jan 16, 2017 at 12:31 PM, Sean Silva <chisophugis at gmail.com> wrote: > Do we have any open projects on LLD? > > I know we usually try to avoid any big "projects" and mainly add/fix > things in response to user needs, but just wondering if somebody has any > ideas. > > Some really generic/simple stuff I can think of: > 1. trying out LLD on a large

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

Replying to the thread, not just the email since I was on vacations. First, note that there is a nomenclature issue. A section in ELF/COFF is closer to an atom in MachO than a MachO section IMHO. A rose by any other name would smell as sweet, but sure as hell creates a lot of confusion :-) On 4 May 2015 at 18:05, Chris Lattner <clattner at apple.com> wrote: > On May 4, 2015, at 1:16

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

On Tue, Jun 6, 2017 at 11:14 PM, Michael Clark via llvm-dev < llvm-dev at lists.llvm.org> wrote: > OK. I see that the Mach-O linker is not even built when LLD is enabled in > Release_40, only the PE/COFF and ELF linkers are built. > > From looking at reviews it appears that Clang was able to be linked with > LLD on Darwin about 2 years ago, so Mach-O support seems to have

On May 1, 2015, at 12:31 PM, Rui Ueyama <ruiu at google.com> wrote: > Proposal > Re-architect the linker based on the section model where it’s appropriate. > Stop simulating different linker semantics using the Unix model. Instead, directly implement the native behavior. Preface: I have never personally contributed code to LLD, so don’t take anything I’m about to say too seriously.