Re: Exceptions, C++

[Charles-Antoine Gauthier <charles.gauthier@nrc.ca>]

Eric Norum wrote:
> 
> Thanks for the reply.  I'll try and provide a bit more detail on what
> I'm seeing.  The quick summary is that __register_frame_info isn't being
> called, and I don't know how to get it to be called!

Should it be? In except.c, you can read that some configurations of gcc
do not call __register_frame_info. You almost certainly are not using
DWARF2 frame unwind info nor crtstuff.c (this is something I added to
m68k-rtemself), so I don't think that function is supposed to be called.

   Each object file that is compiled with exception handling contains
   a static array of exception handlers named __EXCEPTION_TABLE__.
   Each entry contains the starting and ending addresses of the
   exception region, and the address of the handler designated for
   that region.

   If the target does not use the DWARF 2 frame unwind information, at
   program startup each object file invokes a function named
   __register_exceptions with the address of its local
   __EXCEPTION_TABLE__. __register_exceptions is defined in libgcc2.c,
and
   is responsible for recording all of the exception regions into one
list
   (which is kept in a static variable named exception_table_list).

   On targets that support crtstuff.c, the unwind information
   is stored in a section named .eh_frame and the information for the
   entire shared object or program is registered with a call to
   __register_frame_info.  On other targets, the information for each
   translation unit is registered from the file generated by collect2.
   __register_frame_info is defined in frame.c, and is responsible for
   recording all of the unwind regions into one list (which is kept in a
   static variable named unwind_table_list).

The text is not clear on what collect2 should be doing for you.
Presummably, the tool collects the required calls to
__register_exceptions into some function or section. Then what? What is
clear is that something is not working for you. Sorry, but I don't
currently have a m68k-rtems compiler and cannot investigate further.

> Charles-Antoine Gauthier wrote:
> >
> > 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
> > program.
> 
> The __throw() routine that's being used is from libgcc2.c.
> 
> >
> > 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.
> 
> Yeah, that seems to be the problem.  I see that __throw is calling
> __terminate because find_fde can not find the frame -- because find_fde
> uses the `objects' pointer, which is NULL.   This pointer is set by the
> __register_frame_info routine which is never being called.
> 
> This sounds like a linker/runtime problem.
> 
> The compiler produces exception information at the end of main.cc.  It
> starts out something like:
> .section        .gcc_except_table,"d"
>         .even
> __EXCEPTION_TABLE__:
>         .long .LEHB67
> My linker script is putting the .gcc_except_table section into the .data
> section of the executable.
> 
> Can anyone out there help with this??

So you know you are getting the __EXCEPTION_TABLE__. Where is the call
to __register_exceptions?

> 
> Thanks,
> --
> Eric Norum                                 eric@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