Re: Problems with g++ and exceptions, version 2.9-gnupro-98r2

["Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>]

> we have a problem with the Cygnus g++ compiler, version 2.9-gnupro-98r2

Thanks for your bug report. This is the support list for gcc; support
for Cygnus releases of gcc is available through different channels.

> When we use exceptions in our source code and compile with option
> -fno-rtti (in detail: "g++ -fno-rtti tescht.C", our program crashes
> as soon as an exception has been thrown and handled in the
> corresponding "catch" block. It makes no difference which kind of
> object is thrown as exception, neither in which "catch" block it is
> handled.

This does not seem like a bug to me. Exception handling is not
supposed to work fully with -fno-rtti.

> Unfortunately, we are
> a) forced to use -fno-rtti and
> b) are not able to switch to a more recent version of the compiler.

I was going to suggest one of these things to you (actually, both of
them). With these two options gone, not much are left... Let me answer
your questions in a different order.

> Are there patches for this problem?

You really need to ask Cygnus for that. I don't have the exact sources
to the compiler, let alone patches... Hopefully, you have the sources
to the compiler - you may need to change them.

> Are there compiler switches we haven't recognised yet?

I don't think so, no.

> Do you have any ideas how we can solve this problem? 

There are several approaches, all involving changes to the compiler.

A) fix the generated code so that the throw type matcher won't crash
   If you look at the generated code (actually, the one generated by 
   2.95.2) you'll see

	pushl $0
	pushl $.LC2
	pushl %esi
	call __cp_push_exception

   If you compare this to the signature, you see 

extern "C" void
__cp_push_exception (void *value, void *type, void (*cleanup)(void *, int))

   Here, %esi is value, $0 is cleanup. type is supposed to be an RTTI
   object. Since you were asking for no RTTI, all the compiler generates
   is

.LC2:
	.string	"c"

   which represents "char". So you'd need to extend the EH interface
   to expect strings as type representations instead of type_info
   objects. That is a lot of work, but certainly possible. You may
   look at the gcc 2.7 or older sources for inspiration.

B) Fix whatever linker errors you get. I guess it is the type-info
   functions and objects that are missing. GCC will emit this stuff
   together with the first non-inline non-pure virtual function -
   unless -fno-rtti was specified when compiling this function.

   So to get the type info for the base classes generated, use the
   following procedure:
   1) Determine the first non-inline non-pure virtual function.
   2) write a C++ file implementing only this function. You probably
      don't know what the implementation should be - an empty
      implementation will do.
   3) Compile this file into assembler code. GCC will emit the missing
      symbols.
   4) Edit the assembler code, and remove the implementation of the
      virtual function, so that the one of the library is used.
   5) Compile the assmbler code, and link it with application.

Hope this helps,
Martin