search for: kapoulkine

----- 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: ELF/COFF main() interface > > On 26 January 2016 at 00:01, Yaron Keren via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > The context issue may be...

...e there is significantly larger. Am I missing any other issues except for the ones I mentioned in my original e-mail that will come up in a library-like usage scenario? Arseny On Thu, Jan 7, 2016 at 7:17 AM, Rui Ueyama <ruiu at google.com> 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 >> importance for my use case): >> >> 1. Detecting e...

...rs, such as --whole-archive/--no-whole-archive, affects how files in between will be interpreted, so you can't separate command line parameters from a list of files.) I think this is a practical solution that we can do now. I can implement this for you. On Thu, Jan 21, 2016 at 9:28 PM, Arseny Kapoulkine < arseny.kapoulkine at gmail.com> wrote: > > In any case, I have simply wasted too much time on a thread with > someone with no patches on the new elf linker. It is really annoying that > you don't put effort into it and seem entitled to dictate its direction. > > Sorry...

...cts how files in between will be interpreted, so you can't separate >> command line parameters from a list of files.) >> >> I think this is a practical solution that we can do now. I can implement >> this for you. >> >> On Thu, Jan 21, 2016 at 9:28 PM, Arseny Kapoulkine < >> arseny.kapoulkine at gmail.com> wrote: >> >>> > In any case, I have simply wasted too much time on a thread with >>> someone with no patches on the new elf linker. It is really annoying that >>> you don't put effort into it and seem entitled...

...ions that do not fit perfectly within the established framework. I do not understand the resistance to not using global state and propagating errors to the top level. Arseny On Thu, Jan 21, 2016 at 2:54 PM, Rui Ueyama <ruiu at google.com> wrote: > On Thu, Jan 21, 2016 at 2:15 PM, Arseny Kapoulkine < > arseny.kapoulkine at gmail.com> wrote: > >> 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 wou...

In the process of migrating from old lld ELF linker to new (previously ELF2) I noticed the interface lost several important features (ordered by importance for my use case): 1. Detecting errors in the first place. New linker seems to call exit(1) for any error. 2. Reporting messages to non-stderr outputs. Previously all link functions had a raw_ostream argument so it was possible to delay the

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 >> importance for my use case): >> >> 1. Detecting e...

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

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

> 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

...ogle.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 < >>> 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 >>>> importance for my use...

...ker tool and i don't think anyone has any problem with that, but there is also a clear desire from folks to have it be usable as a library and I would hope any patches to do so are accepted, even if they make the code more complex, or slower. >>> On Thu, Jan 7, 2016 at 7:03 AM, Arseny Kapoulkine via llvm-dev < >>> llvm-dev at lists.llvm.org <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>> wrote: >>> >>>> In the process of migrating from old lld ELF linker to new (previously >>>> ELF2) I noticed the interface lost several impor...

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

...think anyone has any problem with that, but there > is also a clear desire from folks to have it be usable as a library and I > would hope any patches to do so are accepted, even if they make the code > more complex, or slower. > > >>>* On Thu, Jan 7, 2016 at 7:03 AM, Arseny Kapoulkine via llvm-dev < > *>>>* llvm-dev at lists.llvm.org <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>> wrote: > *>>>>>>>* In the process of migrating from old lld ELF linker to new (previously > *>>>>* ELF2) I noticed the interfac...

...nd i don't think anyone has any problem with that, but there is also a clear desire from folks to have it be usable as a library and I would hope any patches to do so are accepted, even if they make the code more complex, or slower. > > >>> On Thu, Jan 7, 2016 at 7:03 AM, Arseny Kapoulkine via llvm-dev < > >>> llvm-dev at lists.llvm.org <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>> wrote: > >>> > >>>> In the process of migrating from old lld ELF linker to new (previously > >>>> ELF2) I noticed the interfac...

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

...'t think anyone has any problem with that, but there is also a clear desire from folks to have it be usable as a library and I would hope any patches to do so are accepted, even if they make the code more complex, or slower. >> >> >>> On Thu, Jan 7, 2016 at 7:03 AM, Arseny Kapoulkine via llvm-dev < >> >>> llvm-dev at lists.llvm.org <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>> wrote: >> >>> >> >>>> In the process of migrating from old lld ELF linker to new (previously >> >>>> ELF2) I noti...

...but there >>> is also a clear desire from folks to have it be usable as a library and I >>> would hope any patches to do so are accepted, even if they make the code >>> more complex, or slower. >>> >>> >>>* On Thu, Jan 7, 2016 at 7:03 AM, Arseny Kapoulkine via llvm-dev < >>> *>>>* llvm-dev at lists.llvm.org <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>> wrote: >>> *>>>>>>>* In the process of migrating from old lld ELF linker to new (previously >>> *>>>>* ELF2...

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

...hink anyone has any problem with that, but there is also a clear desire from folks to have it be usable as a library and I would hope any patches to do so are accepted, even if they make the code more complex, or slower. >>> >>> >>> On Thu, Jan 7, 2016 at 7:03 AM, Arseny Kapoulkine via llvm-dev < >>> >>> llvm-dev at lists.llvm.org <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>> wrote: >>> >>> >>> >>>> In the process of migrating from old lld ELF linker to new (previously >>> >>>&...