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

[Hal Finkel via llvm-dev]

----- Original Message -----
> From: "ChrisBieneman" <cbieneman at apple.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Rafael Espíndola" <rafael.espindola at gmail.com>, "llvm-dev" <llvm-dev at lists.llvm.org>, "Arseny Kapoulkine"
> <arseny.kapoulkine at gmail.com>
> Sent: Tuesday, January 26, 2016 11:35:09 AM
> Subject: Re: [llvm-dev] lld: ELF/COFF main() interface
> 
> 
> 
> > 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).

I'm well aware ;)

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

Fair enough. To be honest, however, our error-handling story in LLVM is really pretty poor too, and some judicious use of exceptions could make things better. That having been said, having functions that might throw everywhere does harm the ability of the optimizer to do its work, and so I suspect we'll always want to support building with them disabled. You're correct, however, that we might want to make a higher-level decision about this (i.e. not in this thread).

 -Hal

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

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory