similar to: [LLVMdev] New linker ownership

Hi Rui, > so I'd like to be an owner of the new linkers (both for ELF and COFF), ... Sounds good to me. Do you mind if I add myself as a code owner for LLD Core / MachO, since I'll be continuing to work on that? Cheers, Lang. On Wed, Jul 15, 2015 at 2:17 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 15 July 2015 at 00:08, Rui Ueyama <ruiu at google.com>

On Sat, Jan 6, 2018 at 8:56 AM, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > > On Fri, Jan 5, 2018 at 2:30 AM Rui Ueyama <ruiu at google.com> wrote: > >> Thank you for starting the discussion thread. >> >> In general I'm in favor of the proposal. Defining a generic way to convey >> some information from the compiler to the linker is

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 12 September 2016 at 16:23, Rui Ueyama <ruiu at google.com> wrote: > What's the motivation to not build COFF and Mach-O parts? If you don't need > it, you could just leave it. Are you trying to reduce the executable size? It was just easier to remove coff::link() and mach_o::link() from lld.cpp than to add them to our own build infrastructure

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

This is really unfortunate. I've read the discussion threads for the atom/chunk controversy and I feel like I understand the reasons for rewriting the linker, but this does not seem to have anything to do with whether the linker is usable as a library or not. As it stands, not only does lld have two completely different linkers (I'm treating COFF/ELF2 as one since they are really two

On Fri, May 1, 2015 at 1:32 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Fri, May 1, 2015 at 12:31 PM, Rui Ueyama <ruiu at google.com> wrote: > > Caveat Why not define a section as an atom and keep using the atom > model? If > > we do this, we would have to allow atoms to have more than one name. Each > > name would have an offset in the atom (to

On Fri, Jan 5, 2018 at 2:30 AM Rui Ueyama <ruiu at google.com> wrote: > Thank you for starting the discussion thread. > > In general I'm in favor of the proposal. Defining a generic way to convey > some information from the compiler to the linker is useful, and it looks > like it is just a historical reason that the ELF lacks the feature at the > moment. > > This

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

On Tue, Dec 13, 2016 at 12:08 PM, Rui Ueyama <ruiu at google.com> wrote: > 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 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 >

Yes, that would be the long term plan. llvm-link ideally would share the same library. I'm not sure where it should live though. On Tue 14 Feb 2017 at 01:49, Rui Ueyama <ruiu at google.com> wrote: > I took a look at the code. Looks like you need a library to create import > library files in LLVM and use that from llvm-dlltool and LLD. Is that what > you are planning? > >

----- Original Message ----- > 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 > Subject: Re: [llvm-dev] LLD status update and performance chart > On Tue, Dec 13, 2016 at 12:08 PM, Rui

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

Ohh nice. With that method I can support it without upsetting ld users by introducing an api breakage. On Tue 14 Feb 2017 at 01:32, Rui Ueyama <ruiu at google.com> wrote: > On Mon, Feb 13, 2017 at 5:26 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > > On Mon, Feb 13, 2017 at 5:20 PM, Rui Ueyama via llvm-dev < > llvm-dev at lists.llvm.org> 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 13, 2016 at 11:23 AM, Mehdi Amini <mehdi.amini at apple.com> > wrote: > >> >> On Dec 13, 2016, at 11:08 AM, Rui Ueyama <ruiu at google.com> wrote: >> >> On Tue, Dec

> > If you want to define an alias symbol "bar" to "foo" (which is an > extension you want to provide), one way is to create an object file that > defines "bar" and "__imp_bar" as aliases to "foo" and "__imp_foo", > respectively, and add that object file to the import library. As a result, > the import library file

On Thu, Jan 7, 2016 at 4:05 PM Rui Ueyama <ruiu at google.com> wrote: > By organizing it as a library, I'm expecting something coarse. I don't > expect to reorganize the linker itself as a collection of small libraries, > but make the entire linker available as a library, so that you can link > stuff in-process. More specifically, I expect that the library would >

Usage of the builtin appears independent of LTO, see below. With any of -fno-builtin, -fno-builtin-memcpy, and -ffreestanding, which are all typically used to prevent usage of memcpy calls, we still always get a memcpy builtin in TlsDriverEntryPoint(). I see this even without -flto (e.g. try with just -emit-llvm). I guess it is because this memcpy is not coming from the original source, but

Thanks for the response, Rui! On Tue, Jun 5, 2018 at 5:26 PM, Rui Ueyama <ruiu at google.com> wrote: > > Besides the features you pointed out, I think Xcode introduced a new way > of listing dynamic linking symbols, and I believe lld doesn't support that. > .tbd files, is that right? A colleague of mine pointed me to Apple's libtapi open source project [1], maybe I can