On Sat, Jan 15, 2011 at 08:09:16PM -0800, Ian Lance Taylor wrote: > Bob Rossi <bob@xxxxxxxxxx> writes: > > > I've got a main C++ executable that I am linking with > > -static-libgcc and libstdc++.a. This works fine. > > I'm doing this to make linux distribution easier. > > > > I've also got a C shared object library which I load from the > > main executable. The C shared object library, has function pointers > > which get registered in it from the main executable. So this happens, > > - the main executable loads the shared object > > - the main executable sets function pointers in the shared object > > - the main executable calls a function in the loaded shared object file > > - the shared object file calls a function pointer getting back into > > the main executable > > - an exception is thrown from the main executable (nested in the call > > stack of the shared object) > > - the exception propogates through the shared object interface and > > is caught in the main executable again. > > > > Is this use of -static-libgcc, libstdc++.a, shared objects and > > exceptions safe in all known configurations? > > > > I'm worried about this text from the gcc documentation related > > to the static-ligcc option, > > There are several situations in which an application should use > > the shared libgcc instead of the static version. The most common > > of these is when the application wishes to throw and catch > > exceptions across different shared libraries. In that case, each > > of the libraries as well as the application itself should use the > > shared libgcc. > > although, I don't think what I'm doing is related to what this text > > is discussing. Thanks for this answer. > What you describe is not safe in all known configurations. There are > configurations where the unwind library invoked to throw the exception > will not be able to find the unwind information defined by the shared > library, which means that it will not be able to reliably unwind through > the functions in the shared library, and, in particular, will not be > able to run destructors for local variables defined in functions in the > shared library. I'm assumming that you understood that the shared libraries are pure C, with no C++ in them at all. (There won't be any destructors for local variables defined in the shared library since it's pure C.) Only the main executable with throw and catch exceptions. > However, what you describe is safe on current versions of GNU/Linux. It > is safe if 1) your linker supports the --eh-frame-hdr option (binutils > 2.12 ; 2) your glibc provides the dl_iterate_phdr option; 3) your gcc > was configured to be aware of both these facts. These facts have been > true for at least five years on GNU/Linux systems. > > What is the range of configurations you have to consider? Well, essentially any configuration that someone asks to run the software on. Regarding points 1, 2, and 3. Do those have to be true at link time (when i'm building the executable on the machines I control) or at load time (when the user goes to run the executable on the machines they control)? Thanks, Bob
