[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Exceptions, C++

Looks like exception processing half-works. At least you are not
crashing by calling a bogus exception handler. I am fuzzy also on what
is supposed to happen in your configuration. __throw() does not have a
single implementation in gcc, which makes it somewhat difficult to know
what it does unless one goes through the various implementations in
detail. What it does depends on the manifest constants that are set at
configuration time. All that is common is that __throw() does the actual
throwing of the exception. What should happen next is that some function
should scan some data structure (possible the stack) for a handler. In
your case, it could be __terminate(), but that would be a strange name
for such a function. Maybe your __throw does it?. What is obvious is
that the handler is not called. __default_terminate() is the handler
that is called when no user installed handler is found. This function
then calls abort. I assume that in a Unix environment, either
__default_terminate() or abort() would most likely print a description
of the exception that was thrown to stderr before shutting down the

It might be that you are leaving some pieces out of your image. Does the
cdtest/main.o file have a .eh_frame section or any other sections that
you do not recognize? If so, are they linked into the executable image?
Did they get stripped or overwritten during download? I would normally
send the exception handler sections into the .data section. That way,
nothing gets stomped on when the .bss section is zeroed and the storage
pool initialized.

Sorry that I don't have an exact answer to your question. I never tried
to get C++ exceptions working with m68k-rtems. My current environments
look different from yours. My throw function on the powerpc is even
called __sjthrow(). Before the throw, I have calls to
__get_eh_context(), __tfPpc() (which returns an object type descriptor,
I think), and __cp_push_exception(). I think that the last one actually
pushes the exception object and the type code onto the stack for
__sjthrow() to find a matching handler. If __sjthrow() returns,
__terminate() is called. The presence of __tfPpc() might suggest that
runtime type information is being generated by default.

Have a look at egcs/gcc/except.c. It might suggest some flags that you
should throw when compiling main.cc. If you find something that works,
work backwards from there and look at the configuration options. You
might be able to get the compiler to support exception processing by

P.S. I am cross-posting to rtems-list. Maybe someone else with more
knowledge can shed light on the topic.

Eric Norum wrote:
> Charles-Antoine Gauthier wrote:
> >
> > Hum... Last I tried, cdtest worked fine on the MVME167 using
> > m68k-rtemself as the target. The configuration uses ELF format images
> > with DWARF2 debugging info and DWARF2 exception frame info. It uses
> > crti.o, crtbegin.o, crtend.o and crtn.o. The exception tables are
> > initialized at startup with a call to __eh_register_frame_info (or
> > something like that.) The function comes from crtstuff.c. The compiler
> > was gcc 2.95.2 (it also worked with 2.95.1).
> >
> > Since then, I discovered that the m68k-rtemself configuration is not
> > officially supposed to work according to documentation in
> > egcs/gcc/except.c. We are currently in the process of upgrading our
> > development environment (hw and sw) and hope to be done Real Soon Now.
> > Once we are, we will be submitting ports for the MBX860 and MBX821.
> > These now run cdtest properly. As a bonus, they also run gcj code, and
> > Java exception work too! We still need to run the full test suite on
> > these boards to get the timing info.
> >
> > Then we will be in a position to revisit the m68k configuration and see
> > if we can get that to work. I suspect that we should turn off the DWARF2
> > exception table mechanism and fall back to setjump/longjump exception
> > processing. DWARF2 exeception tables were added to support gcj. Support
> > for sjlj exception processing was added to gcj about a month ago. Hence
> > the possibility of rolling back to a supported configuration.
> >
> I'm using gcc-2.95.2 configured for m68k-rtems-coff on my gen68360 BSP.
> When I run cdtest it terminates at the first exception test:
> GLOBAL: Hey I'm in base class constructor number 1 for 0x1a338.
> GLOBAL: Hey I'm in base class constructor number 2 for 0x1a344.
> GLOBAL: Hey I'm in derived class constructor number 3 for 0x1a344.
> LOCAL: Hey I'm in base class constructor number 4 for 0x4403c.
> LOCAL: Hey I'm in base class constructor number 5 for 0x44030.
> LOCAL: Hey I'm in base class constructor number 6 for 0x44024.
> LOCAL: Hey I'm in base class constructor number 7 for 0x44018.
> LOCAL: Hey I'm in derived class constructor number 8 for 0x44018.
> IO Stream not tested
> LOCAL: Hey I'm in derived class destructor number 8 for 0x44018.
> Derived class - Instantiation order 8
> LOCAL: Hey I'm in base class destructor number 7 for 0x44018.
> Instantiation order 8
> LOCAL: Hey I'm in base class destructor number 6 for 0x44024.
> Instantiation order 6
> LOCAL: Hey I'm in base class destructor number 5 for 0x44030.
> Instantiation order 5
> LOCAL: Hey I'm in base class destructor number 4 for 0x4403c.
> Instantiation order 5
> Here's the gdb trace:
> #0  abort () at abort.c:61
> #1  0x1176 in __default_terminate ()
> #2  0x1184 in __terminate ()
> #3  0x185c in __throw ()
> #4  0x868 in foo_function () at main.cc:167
> #5  0xad6 in main_task () at main.cc:191
> Any suggestions?  Is there something in the gld configuration script I
> have to watch out for to get this to work?
> --
> Eric Norum                                 eric at cls.usask.ca
> Canadian Light Source                      Phone: (306) 966-6308
> University of Saskatchewan                 FAX:   (306) 966-6058
> Saskatoon, Canada.

Charles-Antoine Gauthier
Research Officer
Software Engineering Group
Institute for Information Technology
National Research Council of Canada
Ottawa, ON, Canada
K1A 0R6