question about arithmetic exceptions

[Andrew Haley]

> From: Godmar Back <gback@cs.utah.edu>
> Date: Sat, 27 Nov 1999 17:20:49 -0700 (MST)
> 
> In i386-signal.h in the code that handles arithmetic exceptions, 
> I noticed this comment:
> 
>           /* We assume that unsigned divisions are in library code, so  \
>            * we throw one level down the stack, which was hopefully     \
>            * the place that called the library routine.  This will      \
>            * break if the library is ever compiled with                 \
>            * -fomit-frame-pointer, but at least this way we've got a    \
>            * good chance of finding the exception handler. */           \
> 
> Basically, if a division by zero occurs in __divdi3, the
> __divdi3 frame is skipped and unwinding is begun in its caller.
> 
> This is necessary because libgcc2.c:__divdi3  is not compiled with 
> the -fexceptions flag when libgcc.a is built.  If dispatching were
> begun in that frame, __throw would immediately terminate.
> 
> What are the reasons for not giving the -fexceptions flag to 
> the libgcc2.c:__divdi3 portion?

This would be useful only for range based exception handling and only
for Java.  It would increase the size of the object, as range based
exception handling is very expensive in terms of memory size.

I suppose that we could suggest that libgcc2.c:__divdi3 should be
compiled with exception handling information turned on.  However, it
would not improve Java performance one iota.

> I could imagine that people didn't want the exception information
> in C executables that don't make any use of them.  

Right.

> Nevertheless, the hack in libgcj seems suboptimal.

Sure, it's ugly.  However, unless libgcc changes substantially this
hack will continue to work, and it provides all the funtionality we
need without burdening C and C++ with the extra code space usage.

(An aside: I wonder what Ada does in this case?  Ada is also supposed
to be able to catch these exceptions.)

Andrew.