This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

m68k C++ exception handling


Hello,

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:
   http://www.develer.com/uclinux/

This is the test program I'm using:

#include <stdio.h>
void runTest()
{
    printf("Hello world\n");
    throw("Test exception");
}
int main()
{
    try
    {
        runTest();
    }

    catch ( const char *msg )
    {
        printf("Caught exception: %s\n", msg);
    }

    printf("Application completed successfully!\n");

    return 0;
}

This test program outputs:

  Hello world
  Abort

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:

      #define EH_FRAME_IN_DATA_SECTION

   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:

     Hello world
     Illegal instruction

   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.
\X/  http://www.develer.com/

Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]