Re: Exceptions, C++

[Eric Norum <eric@cls.usask.ca>]

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!


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??

Thanks,
-- 
Eric Norum                                 eric@cls.usask.ca
Canadian Light Source                      Phone: (306) 966-6308
University of Saskatchewan                 FAX:   (306) 966-6058
Saskatoon, Canada.