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

[Eric Christopher via llvm-dev]

Very much agreed here.

On Tue, Jan 26, 2016, 9:35 AM ChrisBieneman via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
>
> > 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160126/40ddcb33/attachment.html>