Richard, Thanks for the quick response; it gave me some directions to investigate further, otherwise it seemed I got stuck trying to make sense of many moving pieces in this puzzle. So, my understanding is that generally the run-time exception handling should _not_ depend on the order of the linkage (provided there're no violations as you mentioned). This is unlike the familiar case of order of object files affecting the linker's resolutions of external symbols, where the order _does_ matter. That means what I'm seeing is rather anomalous, not a by-design behavior.
Now, looking into the ideas of the ODR violation, I realise that in the set up I'm using, the clang (installed from pre-built pack...@llvm.org) is used with '-stdlib=libc++', so the link pulls the libc++.dylib and the libc++abi.dylib. The compiler gets clang's libc++ includes, the linker resolves these from clang's /lib, however OSX (10.13) has its own set of these .dynlibs in /usr/lib; system's libSystem pulls these (via libobjc.dylib). So the resulting binary loads two sets of libc++ and libc++abi. Are there any linkages between the clang's supplied libc++ and system's libc++abi, or it's meant to use exclusively clang's libc++? Could this be the reason for exception breakdown? I understand that generally there should be only one libc++abi for the whole application, this way the type_info is common across all classes, and thus exceptions are correctly typed. This may explain why a sample test (try/throw/catch) works in isolation, as it may not cross from one set of libc++abi into the other. I'm thinking what test code could I craft that would possibly trigger the use of both clang's and system's libc++abi? Clearly, the simple try/throw/catch works OK whether with or without -rpath to clang's lib. > Given the symptoms, it's possible that this is happening because part of your > program is built with -fno-exceptions and part of your program is build > without that flag, and an exception in question is propagating through a > (perhaps inline) function that was built both ways. But that's just a guess. I tried to rebuild the whole application with -fexceptions; still the same symptoms. Also tried with -funwind-tables. The issue is present wth -O0 too. Reading on this, back in time Apple was advising Xcode users _not_ to use -no_compact_unwind switch, as it led to similar issue of exceptions not getting caught. Not sure what exactly was the effect of that switch, but clang does not seem to have this switch and, well, exceptions are being caught in isolated sample test. I appreciate your input. _______________________________________________ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
