: >	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 (tv@pobox.com)