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

[Richard Smith via cfe-users]

On Sun, 5 Apr 2020 at 15:31, krokus via cfe-users <cfe-users at lists.llvm.org>
wrote:

> First of all a preface - This problem was spotted while trying to
> build a large C++ project which links a close to 100 of object file
> together, plus libraries. I can't replicate this behavior in a simple
> isolated test. Just want to understand if potentially this may be
> caused by clang's compiler or linker behavior (missed flag, or
> optimization effect/bug). The project builds and runs correctly with
> GCC.
>
> Compiler: clang-10 on OSX 10.13
>
> The project builds fully without errors and the final binary
> executable is produced. The binary starts up ok and presents a prompt.
> However any exception-based processing (like input errors are expected
> to show a message and continue, or catching Ctrl+C and processing into
> a message and continue)  result in uncaught exception and ends in
> abort(). Basically, the libc++ calls std::terminate(), as if the
> proper catch statement is missing, which clearly is in the code.
> Somehow the exception unwind stack gets broken.
>
> The code links a large number of objects and a few .a libraries, so I
> tried to put the individual objects into another .a lib to try to
> eliminate the order effects. Still, the resulting binary has the
> exception catching issues.
>
> Then I tried to craft a simple test (which does not use any of the
> actual project's code)  that has throw/catch and then linked it in the
> same way. The results:
>  * when the test code is linked from the .a library (with all objects
> as above), the exceptions are processed ok.
>  * when the test code is linked with all the objects above specified
> on the command line, the exception issues are back.
>

Only objects that contain referenced symbols get pulled in from archives,
so using a .a library will tend to result in fewer objects being linked in
than specifying the .o files on the command line. That might explain part
of the difference you're seeing here.


> Obviously, the simple test code does not need any of the code from the
> other objects, yet the resulting code appears somehow broken. Granted,
> the linker will  have to resolve all dependecies it finds on the
> command line and tie it into the binary, still none of those functions
> should be executed by the sample test code.
>
> Finally, I tried to change the order of the project's object files at
> line and put the object file which does the actual throw, right next
> to the main's object file. To my surprise, the exceptions were caught
> ok... But too soon to celebrate, exceptions tripped in other parts of
> the code still were not caught properly.
>
> So the bottom line, some how the exceptions table gets messed up in
> the process on linking. I can't think of any other way to diagnose
> this.
>
> By the way, the very same code is properly linked and functioning when
> using GCC default compile/link options.
>
> I tired without success -fno-lto to disable link-time-optimization,
> but that's default anyway.
>
> To reiterate the questions:
> 1. Why would order of the object files matter for correct exception
> processing?
>

The most likely explanation is that your program contains a violation of
C++'s "One Definition Rule" (ODR). Specifically, you probably have a
function or class that's defined in different ways in two different source
files, and the behavior of your program depends on which one gets picked at
link time. (Worse, there are ways in which we can end up picking one
version from one .o file and a different version from a different .o file.)
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.


> 2. Are there some clang's options specific for such cases?
>

Do you still see the issue with -O0? Do you still see the issue if you
explicitly add -fexceptions to every compilation?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-users/attachments/20200405/5b164601/attachment-0001.html>