This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: egcs 2.95.1 exceptions don't work in .so (Solaris) and possible solution
> Could you please send me the modified Makefile you used to get my
> example to work? I tried duplicating your description of how to make
> it work and failed (on both Solaris 2.6 and 7; my only Solaris 2.5.1
> system has a hopelessly out-of-date gcc).
It is attached below. I tried the modified Makefile also on one of our
Solaris 2.6 machines, and the run terminates with
2: ccc
global = 4
global2 = 5
Abort - core dumped
make: *** [run] Error 134
We don't have a Solaris 7 installation yet, so I can't try there. I
have not investigated the Solaris 2.6 crash further, but it looks like
we are seeing the same behaviour. Just don't use Solaris 2.6 :-(
> The cost of sjlj exceptions isn't significant for my application,
> because exceptions aren't supposed to happen and because my try/catch
> is only at the top level.
The problem is that there are costs even without an exception ever
being thrown. For every local variable with a destructor, the compiler
has to explicitly save the context, so that a later longjmp will go to
the right location.
Just consider the difference in assembler code for a program like
struct S{
~S();
};
void f();
int main()
{
S a;
for (int i=0;i<10;i++){
S b;
f();
};
}
> Thank-you for your help. If you can point me at more documentation on
> shared libraries and exceptions, I will investigate this more on my
> own.
In theory, I think the DWARF2 specification should explain how the
stack unwinding is supposed to work; you can find that somewhere at
SGI. Here's a simple overview:
- For each function, the compiler allocates a FDE (frame descriptor
element), which describes register information for a single
function. In particular, the FDE contains the minimum and maximum PC
value for the function.
- All FDEs of an object file are collected into a CIE (common
information element), which is in the .eh_frame section
- The linker combines all CIEs into a single array.
- At run-time, all these array (one per shared library) are collected
into a global list. During a throw, this list is searched to find
the FDE for the function executing the throw, then for its caller,
and so on. If no FDE is found, or an incorrect one is found, bad
things happen.
- The CIE also references the __EXCEPTION_TABLE__ of the object file,
which gives the exception regions for the object file.
If you find any further details, please let me know.
Regards,
Martin
Makefile