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

[Richard Smith via cfe-users]

On Wed, 8 Apr 2020 at 10:14, krokus via cfe-users <cfe-users at lists.llvm.org>
wrote:

> 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++?
>

I'm afraid I don't know exactly how our packages nor the Mac OS X versions
are configured. It's possible there's some mismatch here. If this is
specific to the libc++ dylib that's included in OS X, the Apple folks would
probably be interested in you contacting them directly.

One other thing that sometimes goes wrong when exceptions are thrown but
can't be caught is that the type information on the throw and catch sides
doesn't match, usually because of visibility attributes (or command-line
flags) causing one or both versions of the type to be considered
DSO-internal. Can you catch the exception with "catch (...)"?


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

If you do have two different libc++abis in the same process (maybe one
statically and one dynamically linked?) then it seems plausible that
exception throw/catch would break down, because they would have different
ideas of what some of the key globals involved in exception throw/catch are
(for example, primitive type_info objects).


> 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 at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-users/attachments/20200414/b93e7fe8/attachment.html>