llvm dev - Jan 2016 - lld: ELF/COFF main() interface

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>

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