Is the world coming to an end?

Don nospam at nospam.com
Tue Apr 5 06:09:49 PDT 2011


Nick Sabalausky wrote:
> "spir" <denis.spir at gmail.com> wrote in message 
> news:mailman.3141.1301915290.4748.digitalmars-d at puremagic.com...
>> On 04/04/2011 07:26 AM, Nick Sabalausky wrote:
>>> As far as LDC2, LLVM's uselessness on windows is a bit of a showstopper 
>>> for
>>> many people. And the LLVM project doesn't appear to be interested in 
>>> doing
>>> much about it. (Note I didn't say they *aren't* interested in getting it
>>> working. That's not something I could even pretend to know. I'm just 
>>> saying
>>> that, at the very least, it *looks* like they don't care. And, for better 
>>> or
>>> worse, perception does count for a lot.)
>> Yop, too bad. Else, LLVM could be the one target of choice for many PL's 
>> "reference" implementation. I'd like to know rationales.
>>
> 
> AIUI, the standard explanation is that exception support on Windows requires 
> SEH which is covered by a patent owned by Borland/Microsoft. But I have a 
> hard time buying that explanation because non-MS compilers like GCC and DMC 
> support exceptions on windows just fine - so why not LLVM, too?

AFAICT, that explanation is absolute bollocks.

SEH is *not* covered by a patent. The Borland patent that people talk 
about refers to a particular implementation detail which is a workaround 
for an absolutely horrific Microsoft bug.
The idea is to use the exception handler pointer (which is in 
thread-local storage(TLS)) to track which exception table to use.
Instead of pointing to your exception handler, it points to a thunk (one 
for each try block) which sets a pointer to the try block table, then 
the exception handler.
The reason for doing this, is that you need a TLS slot to store which 
try block you're in.
Unfortunately, Windows' thread local storage is hopelessly broken for 
DLLs. The exception handler pointer is just about the only TLS slot 
guaranteed to be available, so it allows you to escape the bug.

Now since the idea is just a straightforward application of thunks, I 
wonder if it really satisfies the patent requirement for non-obviousness.

But regardless, for D, Rainer has put code into druntime which fixes the 
bug! So actually a D implementation can use any thread-local slot.
<g>


More information about the Digitalmars-d mailing list