Nick Sabalausky wrote:
"spir" <denis.s...@gmail.com> wrote in message
news:mailman.3141.1301915290.4748.digitalmar...@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>