[llvm-dev] lld: ELF/COFF main() interface

Hal Finkel via llvm-dev llvm-dev at lists.llvm.org
Tue Jan 26 09:15:32 PST 2016


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


More information about the llvm-dev mailing list