similar to: lld: ELF/COFF main() interface

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 Thu, Jan 7, 2016 at 7:18 AM Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Jan 7, 2016 at 7:03 AM, Arseny Kapoulkine via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> In the process of migrating from old lld ELF linker to new (previously >> ELF2) I noticed the interface lost several important features (ordered by >>

On Thu, Jan 7, 2016 at 3:18 PM Rui Ueyama <ruiu at google.com> wrote: > On Thu, Jan 7, 2016 at 2:56 PM, Chandler Carruth <chandlerc at gmail.com> > wrote: > >> On Thu, Jan 7, 2016 at 7:18 AM Rui Ueyama via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> On Thu, Jan 7, 2016 at 7:03 AM, Arseny Kapoulkine via llvm-dev < >>>

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 >

On Thu, Jan 7, 2016 at 6:07 PM, Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Jan 7, 2016 at 5:12 PM, Chandler Carruth <chandlerc at gmail.com> > wrote: > >> 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 >>>

> So the situation for LLD being used as a library is analogous to LLVM IR libraries being used from clang. In general, clang knows that it just generated the IR and that the IR is correct (otherwise it would be a bug in clang), and thus it disables the verifier. That sounds good, but we can only usually trust our inputs. There are still some awfully crusty object files out in the world, so we

> If I were a user, I definitely want the former instead of the latter because the former just provides more. This is if you wanted to use the library (e.g. embed linker into clang, do parallel linking of many executables from the same process, etc.). For some use cases there's no difference because the only thing you'll do with a library is link it into a command-line executable and

The context issue may be solved by making all functions and context data members of a class. Sort of having the convenience of global variables accessible from all linker functions but without the regular global variable problems of initializing and re-entry. so the class is suitable aspart of a library. Most clang and LLVM classes works this way, not passing contexts around. 2016-01-22 6:25

----- Original Message ----- > From: "Rafael Espíndola via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Yaron Keren" <yaron.keren at gmail.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Arseny Kapoulkine" <arseny.kapoulkine at gmail.com> > Sent: Tuesday, January 26, 2016 9:39:34 AM > Subject: Re: [llvm-dev] lld:

As a person who started this thread I should probably comment on the interface. My needs only require a library-like version of a command-line interface. Just to be specific, the interface that would work okay is the old high-level lld interface: bool link(ArrayRef<const char*> args, raw_ostream& diagnostics) This would require round-tripping data through files which is not ideal but

I think I have an idea to cover your need and possibly other people's on this thread. It provides the "main() as a library function" feature, input/output files wouldn't go through disks nor file systems, and it doesn't require any major design changes. Sounds too good? That is, we can provide a function that takes command line parameters, do fork, and call the linker's

If you want to link ELF object files, you are likely to be using a Unix machine. I'm not trying to address all possible problems but suggesting a practical solution. On Fri, Jan 22, 2016 at 9:49 AM, Yaron Keren <yaron.keren at gmail.com> wrote: > On Windows fork() is not available. If exec() is used instead, process > creation time is several times slower than Linux. This may be

> Also, one of the other possible motivations of using LLD directly from Clang would be to avoid process overhead on operating systems where that is a much more significant part of the compile time cost. We could today actually take the fork out of the Clang driver because the Clang frontend *is* designed in this way. But we would also need LLD to work in this way. Then go change clang and

Hi Rui I agree separating the components out in to libraries only makes sense when there is a clear reason to do so. However, just this year there was a very involved discussion about what it means to be a library. Specifically, I don't think your current 'main-as-library' argument is valid while you call exit or (if you) rely on mutable global state. Having a single entry point

> On Dec 16, 2016, at 11:46 AM, Rui Ueyama <ruiu at google.com> wrote: > > On Fri, Dec 16, 2016 at 11:18 AM, Pete Cooper <peter_cooper at apple.com <mailto:peter_cooper at apple.com>> wrote: > Hi Rui > > I agree separating the components out in to libraries only makes sense when there is a clear reason to do so. However, just this year there was a very

On Fri, Dec 16, 2016 at 11:18 AM, Pete Cooper <peter_cooper at apple.com> wrote: > Hi Rui > > I agree separating the components out in to libraries only makes sense > when there is a clear reason to do so. However, just this year there was a > very involved discussion about what it means to be a library. > Specifically, I don't think your current

> On Dec 17, 2016, at 6:32 PM, Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Fri, Dec 16, 2016 at 12:31 PM, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > >> On Dec 16, 2016, at 11:46 AM, Rui Ueyama <ruiu at google.com <mailto:ruiu at google.com>> wrote: >>

> There are probably others, but this is the gist of it. Now, you could still > design everything with the simplest imaginable API, that is incredibly > narrow and specialized for a *single* user. But there are still fundamentals > of the style of code that are absolutely necessary to build a library. And > the only way to make sure we get this right, is to have the single user of

On Sat, Dec 17, 2016 at 6:45 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Dec 17, 2016, at 6:32 PM, Sean Silva via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > On Fri, Dec 16, 2016 at 12:31 PM, Pete Cooper via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> On Dec 16, 2016, at 11:46 AM, Rui Ueyama <ruiu at

> On Dec 17, 2016, at 6:54 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > > On Sat, Dec 17, 2016 at 6:45 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > >> On Dec 17, 2016, at 6:32 PM, Sean Silva via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>