[cfe-users] order of object files at link affects exception catching

[krokus via cfe-users]

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
package at 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.