<div dir="auto"><div><div class="gmail_quote"><div dir="ltr">Michael Van Canneyt <<a href="mailto:michael@freepascal.org">michael@freepascal.org</a>> schrieb am Do., 25. Okt. 2018, 11:51:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On Thu, 25 Oct 2018, Sven Barth via fpc-devel wrote:<br>
<br>
> Michael Van Canneyt <<a href="mailto:michael@freepascal.org" target="_blank" rel="noreferrer">michael@freepascal.org</a>> schrieb am Do., 25. Okt. 2018,<br>
> 09:38:<br>
><br>
>><br>
>><br>
>> On Sat, 20 Oct 2018, Simon Kissel wrote:<br>
>><br>
>>> - Make Exception handling, TLS etc use the infrastructure that<br>
>>>  libpthread is providing<br>
>><br>
>> TLS is handled already by libpthread. I doubt you will gain much there.<br>
>><br>
>> However, Exception handling is a problem. There are 2 possible ways ahead:<br>
>> - DWARF exception handling as mentioned by Sven.<br>
>> - Port SEH to be cross platform, this is the approach as taken by Kylix.<br>
>> Kilyx has a small rtlunwind  library that mimics the needed run-time<br>
>> functionality<br>
>> offered by Windows.<br>
>><br>
>> Conceivably, it can be duplicated. wine probably has such a library which<br>
>> can be used as an inspiration.<br>
>><br>
>> The needed compiler infrastructure for SEH  already exists, so this is<br>
>> most likely<br>
>> the fastest way to proceed.<br>
>><br>
><br>
> I'm against emulating SEH. Better implement DWARF exceptions. The<br>
> infrastructure that was created for SEH inside the compiler should help<br>
> nevertheless.<br>
<br>
You can be against, and  you don't need to work on it, <br>
but if someone supplies a patch, I don't think we should refuse it.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I don't agree here. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Personally I am also in favour of a more open technique instead of a<br>
technique which is proprietary to a platform, and in this sense I understand<br>
and endorse your point of view, but beggars can't be choosers.<br>
<br>
There is no problem to have both techniques available. As I wrote, the SEH<br>
is the fastest path.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I have my doubts especially as the rtlunwind stuff of Kylix only works on i386. The SEH mechanism between i386 and all other Windows platforms differs significantly and I doubt that Simon only wants i386 to benefit. </div><div dir="auto"><br></div><div dir="auto">Regards, </div><div dir="auto">Sven </div></div>