This is the mail archive of the
mailing list for the GCC project.
m68k C++ exception handling
- From: Bernardo Innocenti <bernie at develer dot com>
- To: gcc at gcc dot gnu dot org
- Cc: Peter Barada <pbarada at mail dot wm dot sps dot mot dot com>,uClinux development list <uclinux-dev at uclinux dot org>,<paulg at multitrode dot com dot au>
- Date: Sun, 17 Aug 2003 04:11:44 +0200
- Subject: m68k C++ exception handling
- Organization: Develer S.r.l.
C++ exceptions handling appears to be broken on m68k in both GCC 3.3.1 and
CVS HEAD (I've tested only on ColdFire targets). This didn't work also in
GCC 2.95.3 with the uClinux patches I've ported forward, so the cause
might be identical.
For reference, all ColdFire/uClinux patches I'm using are available here:
This is the test program I'm using:
catch ( const char *msg )
printf("Caught exception: %s\n", msg);
printf("Application completed successfully!\n");
This test program outputs:
The generated code for m68k looks quite similar to x86.
I've managed to dig into the EH machinery with a remote GDB
session, but eventually got lost in the complexity (I have
no working breakpoints ;-).
These are some of my findings:
- the program exits through abort(), invoked by uw_init_context_1()
because this test fails:
if (uw_frame_state_for (context, &fs) != _URC_NO_REASON)
- my target uses DWARF2 eh, but places the undwinding information in the
data section instead of using the eh_frame section, since the target
binary format is not really ELF. This is done with:
in the target configuration header. I'm not sure is this is supposed
to work. Is there any other known-good target doing this?
- I tried switching to setjmp()/longjmp() exceptions by putting
#define DWARF2_UNWIND_INFO 0
in the target configuration, but only managed to get my test to
crash like this:
The stack frame says:
#0 0x0022eed0 in ?? ()
#1 0x001e6766 in _Unwind_SjLj_Resume (exc=0x22ef08) at unwind.inc:227
#2 0x001e60f6 in main ()
Code at frame #0 appears to be just rubbish (zeroes, etc.). Both netbsd
and openbsd use sjlj exceptions, so I would expect tgese to work.
Some random questions:
- does the EH handling rely on frame-pointers? Is it supposed to work
on all platforms even with -fomit-frame-pointers?
- Where is the stuff going into the eh_frame emitted? How do I tell
if it's valid?
- How does the runtime code find the eh_frame data, and how is it
associated with the current stack frame?
- How are __builtin_extract_return_addr() and __builtin_return_address()
supposed to work? Do they need some special support in back-ends?
- It's way possible that the EH stuff works fine on all m68k platforms
except ColdFire, perhaps because of the different frame layout.
I'd really much like to know if the test program works on other
m68k targets and on embedded boards (no uClinux).
// Bernardo Innocenti - Develer S.r.l., R&D dept.
Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html