Subject: Re: g++ exceptions
To: None <email@example.com>
From: Todd Vierling <firstname.lastname@example.org>
Date: 04/21/2000 12:42:14
: > I just tried a c++ program that uses exceptions.
: >It didn't work. "Abort (core dumped)" as soon as an.
: >exception is thrown.
: Did you compile with "c++" or just "cc"? If you compile with "cc",
: then sometimes C++ code compiles but doesn't get the right startup
: libraries linked in, causing htte code to die at runtime.
Exception handling stuff is in libgcc.a. Nothing should die at _runtime_ by
the selection of "c++" vs. "cc"--things should only fail at link time by not
including -lstdc++ for standard C++ classes and objects.
: It's a known binutils/i386-elf (or maybe elf on all archs?) problem.
Which is temporarily fixed by -fsjlj-exceptions, so this could be fixed in
the meantime by the following in gcc/config/i386/netbsd-elf.h:
#define DWARF2_UNWIND_INFO 0
This turns off the DWARF2 unwinding of stack frames for exceptions, and thus
forces setjmp-longjmp exception handling.
Note that this will require a recompile of the compiler, libgcc, _and_
libstdc++[*], as it changes the ABI of exception handling. Since exceptions
don't work now, this should be OK--after all, if "new" can't allocate
memory, it throws a bad_alloc exception. 8^)
Of course, this means another ABI change once gcc is switched back to
DWARF2, so that can be scheduled for a known ABI change (such as upgrading
to gcc 2.9x/3.0x, which makes other ABI changes at the same time).
[*] I don't think a major bump is necessary, given that 1.5 is still in an
active development phase, but a minor number bump may at least help visually
to detect when someone has a "bad" compile of the libstdc++ library.
-- Todd Vierling (email@example.com)