On 21/08/2014, at 11:01 PM, Shayne Fletcher wrote: > > On Thu, Aug 21, 2014 at 8:48 AM, john skaller <skal...@users.sourceforge.net> > wrote: > I'm not surprised. Gcc used to have this bug too, but it was fixed. > Identifying exceptions that transit dynamic loading boundaries is non-trvial. > > Is that what it is? I do recall for years exceptions that went across shared > library boundaries weren't supported. Then they were with 'special' > compilation flags. Sad to see this regression.
It's not a regression: it was fixed in gcc. But I'm using clang 3.3svn, and I cannot build a more recent version. Last time I tried it crashed because the config script failed to correctly check on libxml2, which was used somewhere in some tool or test or something, but left me with a broken build .. after the compilation ran for 2 days. The clang people have much worse documentation that Felix. The web page doesn't tell you how to build without DEBUG+ASSERTS. The make file does .. AFTER it is finished. In fact I want to build only the compiler and basic tools (and library), and I only want the X86_64 back end for OSX 10,6.8. I'm sure one can build just that but I have no idea how. The docs are woeful (considering the number or people working on it, and the fact it is funded .. so lets not compare it with Felix docs :) There is a binary tarball .. but it's for OSX Mavericks which I also cannot install: not enough internet bandwidth to download, and living on a boat and money makes taking the box into a shop problematic too. I need a new computer. the bottom line here is that the clang people didn't learn. LLVM is built with a special subroutine call with trampoline support for exceptions but obviously this instruction is wrong. The problem is that with dynamic loading, it is NOT possible to guarantee RTTI, vtables, or function pointers are unique. To catch an exception, one must use the C++ RTTI comparison function (required by the ISO C++ Standard) for identification, or some other mechanism, and make sure the mangled name of the type is unique for the type, that is, the same in all DLLs (which it should be if the mangled name of the base type is used). This is expensive and can't be done by a "machine instruction", it requires a library function to do the check, basically the check has to be done on the string name (the linker name). Pointer comparisons are faster but they do not work. As an aside, LLVM is a misnomer. It has some low level instructions like add and multiply, but subroutine call is not low level: the parameter passing method is undefined. This is stupid. What's worse you have the two calls (plain and with trampoline) but there is no exchange of control instruction (branch and link) which is more fundamental. Unfortunately the IR used by LLVM is a graph based on SSA form with blocks and phi-nodes, which is the basic structure used for flow analysis. It seemed like a good idea at the time, but the whole analysis collapses if you have indirect jumps (i.e. jumps to unknown places). This cannot happen in standard C/C++ but it can and DOES happen when you have a computed goto, and both gcc and clang purport to support that. Clangs support is broken of necessity because an arbitrary computed jump can't be analysed, so the IR invariant is broken. Next time someone designs a virtual machine they should actually learn some computer science first. They had to add a special calling protocol just to support Haskell because it tends to use CPS, which means functions get passed a continuation invoked at the end, and the continuation is effectively and arbitrary goto. Definitely requires tail call optimisation :-) OK, so clang people decided to use C++ instead of C and gcc people finally had to copy them or get squashed. WTF didn't they use Ocaml?? C++ is not much better than C for writing a compiler. Ocaml kills it hands down. -- john skaller skal...@users.sourceforge.net http://felix-lang.org ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
