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

ChrisBieneman via llvm-dev llvm-dev at lists.llvm.org
Tue Jan 26 09:35:09 PST 2016



> On Jan 26, 2016, at 9:15 AM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> ----- 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?

Using exceptions inside an LLVM project would be a significant deviation from the LLVM coding standards (http://llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions).

Not saying we shouldn't do it (although I would strongly prefer if we didn't because exceptions make my skin crawl), but if we want to go down that path there should be a larger discussion about what it means to introduce exceptions.

-Chris

> 
> -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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


More information about the llvm-dev mailing list