<p dir="ltr">Very much agreed here. </p>
<br><div class="gmail_quote"><div dir="ltr">On Tue, Jan 26, 2016, 9:35 AM ChrisBieneman via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On Jan 26, 2016, at 9:15 AM, Hal Finkel via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> ----- Original Message -----<br>
>> From: "Rafael Espíndola via llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
>> To: "Yaron Keren" <<a href="mailto:yaron.keren@gmail.com" target="_blank">yaron.keren@gmail.com</a>><br>
>> Cc: "llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>, "Arseny Kapoulkine" <<a href="mailto:arseny.kapoulkine@gmail.com" target="_blank">arseny.kapoulkine@gmail.com</a>><br>
>> Sent: Tuesday, January 26, 2016 9:39:34 AM<br>
>> Subject: Re: [llvm-dev] lld: ELF/COFF main() interface<br>
>><br>
>> On 26 January 2016 at 00:01, Yaron Keren via llvm-dev<br>
>> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>>> The context issue may be solved by making all functions and context<br>
>>> data<br>
>>> members of a class. Sort of having the convenience of global<br>
>>> variables<br>
>>> accessible from all linker functions but without the regular global<br>
>>> variable<br>
>>> problems of initializing and re-entry. so the class is suitable<br>
>>> aspart of a<br>
>>> library. Most clang and LLVM classes works this way, not passing<br>
>>> contexts<br>
>>> around.<br>
>><br>
>> That is a way to solve the global variable problem. The bigger<br>
>> problem<br>
>> is the error handling. We can use a diagnostic handler instead of<br>
>> calling exit, but we would still need to assume that the handler<br>
>> doesn't return or we would get error_code spaghetti.<br>
><br>
> I believe, however, that even when we want this functionality in a library, we don't want the implementation to be "error_code spaghetti."<br>
><br>
> 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.<br>
><br>
> Thoughts?<br>
<br>
Using exceptions inside an LLVM project would be a significant deviation from the LLVM coding standards (<a href="http://llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions" rel="noreferrer" target="_blank">http://llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions</a>).<br>
<br>
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.<br>
<br>
-Chris<br>
<br>
><br>
> -Hal<br>
><br>
>><br>
>> The main point is that the linker is still evolving. Case in point:<br>
>> we<br>
>> are experimenting on ways to change relocation application to better<br>
>> handle possible optimizations and requirements of other ABIs. Had<br>
>> this<br>
>> already been exposed by a library interface such experiments would be<br>
>> far harder.<br>
>><br>
>> Postponing features is a pretty reasonable thing for a new project.<br>
>> For example, we will probably implement -r, but right now there are<br>
>> other features we want to get designed first. If someone figures out<br>
>> how to make lld a library without a big cost, awesome, but it is not<br>
>> the priority right now.<br>
>><br>
>> Cheers,<br>
>> Rafael<br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
><br>
> --<br>
> Hal Finkel<br>
> Assistant Computational Scientist<br>
> Leadership Computing Facility<br>
> Argonne National Laboratory<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>