search for: arseny

...y? I understand that using global variables and error() function is simpler, but the rest of LLVM does not do that and the codebase 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 no...

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

...ation I'd just throw from error() but lld is probably compiled without exceptions. Is ErrorOr the established practice? How does LLVM generally deal with error handling for parsers (like linker script parser) where it's a lot of mutually recursive functions where every single one can fail? Arseny -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160107/09a9ef49/attachment.html>

...no" after compiling and applying of "strip --strip-unneeded" the sizes decreases to: speexdec.exe is 104.293 bytes speexenc.exe is 132.109 bytes Both tools work with no problems. So I can send this binaries to you if you want to place it online. I'm sure people need it :-) Arseny

...arameters, 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. >...

...I don't really understand where this is coming from, honestly. I understand the frustration of dealing with layers of abstractions 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. >>...

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

...ike LLVM in that I can freely use it in my environment, whereas new lld reminds me of my experience integrating mcpp (a C preprocessor) a few years ago into an in-engine shader compiler with all the same issues (exit() on error, stdout, etc.) that had to be worked around by modifying the codebase. Arseny On Thu, Jan 21, 2016 at 11:14 AM, Chandler Carruth <chandlerc at gmail.com> wrote: > On Thu, Jan 21, 2016 at 10:49 AM Rafael Espíndola < > rafael.espindola at gmail.com> wrote: > >> > There are probably others, but this is the gist of it. Now, you could >> stil...

...ult.xml #Here I see that new line root at xxx:/etc/libvirt/qemu/networks# virsh net-dumpxml default root at xxx:/etc/libvirt/qemu/networks# virsh net-edit default #Here I see exactly the old network definition Is this behaviour expected? If yes, how to just add new host on a running network? -- Arseny Klimovsky

> 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

...main function is fine, but that function cannot then kill the process which its linked in to. If you want context then the relevant piece of the thread is http://lists.llvm.org/pipermail/llvm-dev/2016-January/093760.html <http://lists.llvm.org/pipermail/llvm-dev/2016-January/093760.html>. Arseny summarized things very well there, so i'll just quote him at the end here. I understand that you and others want to first write a fast linker 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 h...

On 7/27/07, Ivo Emanuel Gon?alves <justivo@gmail.com> wrote: > On 7/24/07, Arseny Krasutsky <dtiger@mail.ru> wrote: > > So I can send this binaries to you if you want to place it online. > > I'm sure people need it :-) > > I do not know Jean-Marc's position on this -- it's his project, so I > don't want to meddle -- but if he does not o...

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

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

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

...speed improvement we've made this year. Also, because I was happy about that, I probably emphasized that too much. But that's not our single goal. If you want context then the relevant piece of the thread is > http://lists.llvm.org/pipermail/llvm-dev/2016-January/093760.html. > > Arseny summarized things very well there, so i'll just quote him at the > end here. I understand that you and others want to first write a fast > linker 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 librar...

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

...ts natural that sometimes it'll happen with good reason. Thanks, Pete > > If you want context then the relevant piece of the thread is http://lists.llvm.org/pipermail/llvm-dev/2016-January/093760.html <http://lists.llvm.org/pipermail/llvm-dev/2016-January/093760.html>. > > Arseny summarized things very well there, so i'll just quote him at the end here. I understand that you and others want to first write a fast linker 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 h...

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

...appen with good reason. > > Thanks, > Pete > >> >> If you want context then the relevant piece of the thread is http://lists.llvm.org/pipermail/llvm-dev/2016-January/093760.html <http://lists.llvm.org/pipermail/llvm-dev/2016-January/093760.html>. >> >> Arseny summarized things very well there, so i'll just quote him at the end here. I understand that you and others want to first write a fast linker 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 h...