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 GMT+02:00 Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org>:> There is a trade-off. In order to use main as a library function, all > functions behind it have to pass around a context object, and all functions > that possibly fail have to be wrapped with ErrorOr. Some functions don't > need any context nor they never fail, so maybe we don't have to wrap every > function. But if you later find some leaf function needs a context object > or could fail, you've got to update all function that can reach there. It's > not too hard, but it is all a bit of pain. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160126/44a57471/attachment.html>
Rafael Espíndola via llvm-dev
2016-Jan-26 15:39 UTC
[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 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.That is a way to solve the global variable problem. The bigger problem is the error handling. We can use a diagnostic handler instead of calling exit, but we would still need to assume that the handler doesn't return or we would get error_code spaghetti. The main point is that the linker is still evolving. Case in point: we are experimenting on ways to change relocation application to better handle possible optimizations and requirements of other ABIs. Had this already been exposed by a library interface such experiments would be far harder. Postponing features is a pretty reasonable thing for a new project. For example, we will probably implement -r, but right now there are other features we want to get designed first. If someone figures out how to make lld a library without a big cost, awesome, but it is not the priority right now. Cheers, Rafael
----- 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 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. > > That is a way to solve the global variable problem. The bigger > problem > is the error handling. We can use a diagnostic handler instead of > calling exit, but we would still need to assume that the handler > doesn't return or we would get error_code spaghetti.I believe, however, that even when we want this functionality in a library, we don't want the implementation to be "error_code spaghetti." I propose that, for the purpose of treating lld as a library, we enable exception handling and use C++ exceptions. All of my users who use LLVM components as a library (for JIT, etc.) insist that I build LLVM with exceptions (and RTTI for that matter) enabled. For the purpose of creating a stand-alone lld build, we could certainly build with exceptions disabled if that yields a measurable performance difference. Thoughts? -Hal> > The main point is that the linker is still evolving. Case in point: > we > are experimenting on ways to change relocation application to better > handle possible optimizations and requirements of other ABIs. Had > this > already been exposed by a library interface such experiments would be > far harder. > > Postponing features is a pretty reasonable thing for a new project. > For example, we will probably implement -r, but right now there are > other features we want to get designed first. If someone figures out > how to make lld a library without a big cost, awesome, but it is not > the priority right now. > > Cheers, > Rafael > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory