15

Specifically I'd like to know what, if any, guarantees are made by GCC about how code that throws exceptions behaves when linked against code compiled using -fno-exceptions.

The GNU libstdc++ manual says the following here.

Before detailing the library support for -fno-exceptions, first a passing note on the things lost when this flag is used: it will break exceptions trying to pass through code compiled with -fno-exceptions whether or not that code has any try or catch constructs. If you might have some code that throws, you shouldn't use -fno-exceptions. If you have some code that uses try or catch, you shouldn't use -fno-exceptions.

This sounds like a statement along the lines of, "Thou shalt not...." I.e. undefined behavior.

On the other hand, my impression from this SO question is that everything is kosher as long as the code compiled with -fno-exceptions doesn't throw, try, or catch (obviously a compile-time error) and exceptions never propagate through the functions from this library. And it makes sense: why should the library compiled with -fno-exceptions care if exceptions are thrown so long as they don't interact with its functions?

I did a little tinkering and found that if I compile a simple program using GCC 7.1.1 in which one source file is compiled with -fno-exceptions and the other throws and catches an exception, everything compiles, links, and runs fine. But that doesn't mean this behavior is guaranteed; it could still be undefined.

My motivation in all of this is that I have a situation in which I'm linking my own application code against a library built with -fno-exceptions and, depending on which function calls are made to said library, throwing an exception in my own code causes an immediate segfault even when that exception does not propagate through the library's functions. It smells like a bug in the library to me, but I thought maybe this was permitted when -fno-exceptions was passed during compilation.

GCC's actual reference on code-generation flags mentions -fexceptions relatively briefly and doesn't answer my question. Anyone know of another reference/have relevant experience?

Update: I rebuilt the library from source, this time with exception support turned on. The segfault persists! Time for a bug report.

Sam Marinelli
  • 999
  • 1
  • 6
  • 16
  • 3
    I'd say you're right to think there's no explicit statement that `-fno-exceptions` and `-fexceptions` are compatible but it's implied. However (and here's a crazy point) are you sure you're not passing through any of the library code when you throw an exception. The obvious 'hidden' way that could happen is a `-fno-exceptions` destructor being called (or not called or miss-called) in stack unwinding. Just an idea. – Persixty Aug 29 '17 at 10:29
  • 2
    I don't think that's what's happening in my case since the segfault still occurs even if I put the `throw` directly inside in a `try`/`catch` in `main` as a test. It's never allowed to propagate far enough to trigger any destructors. I just about did a double-take when I read your suggestion though. I certainly hadn't thought of that possibility! – Sam Marinelli Aug 29 '17 at 10:41
  • 2
    You're welcome. Just throwing ideas at you. I'm not that familiar with gcc and certainly not the more exotic configurations. The documentation certainly reads like "here's a bunch of half-arsed bodging to do the very bad thing of disabling exceptions. caveat emptor'. – Persixty Aug 29 '17 at 10:47

1 Answers1

2

As the linked question points out, GCC needs to allow -fno-exceptions and -fexceptions to co-exist, in order to link C and C++.

On a more theoretical level, the exception problem is closely related to the call graph of a program. This is a directed graph (caller/callee) but it can be cyclic, and there can be multiple edges between nodes. Now each function/node can be compiled with or without exceptions. We can define a safe program as a program in which no "with exceptions" node is reachable from a "without exceptions" node.

This may be unnecessarily strict - it might appear reasonable that a C++ bit of code within a try...catch(...) { } block should be callable from C code. But I don't know of a GCC guarantee for that. And consider what it means - the call graph is related to the call stack. The call stack generally forms a path from main() to the currently executing function. If the whole path is exception-aware, then exceptions are safe. But if there's one function which isn't aware of exceptions, it might have put the stack in a state in which exceptions cannot be handled safely, even if stack unwinding wouldn't unwind that far.

MSalters
  • 173,980
  • 10
  • 155
  • 350