question about arithmetic exceptions

[Godmar Back]

 Andrew,

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

Isn't "continue to work" a rather strong statement if you compare it 
to your comment that it'll already break if you compile libgcc with 
-fomit-frame-pointer?

I also agree with you that it's not about performance.  It's about
brittle code IMO.


I believe that the right approach is to first split libgcc2.c into
different source files, grouped by functionality.  For instance, it
could look like this:

libgcc2/arith
libgcc2/arith/divdi3.c
libgcc2/arith/moddi3.c
		...
libgcc2/bb/bb.c
libgcc2/eh/eh.c
...

Etc.

There should be differently compiled versions of some files depending on
what executable is built, i.e., divdi3-noexc and a divdi3-exc from which
the compiler driver could choose when linking an executable.

This mechanism should also solve the problem alluded to earlier, namely
that a gcc installation currently has a single threading system hardwired 
in its run-time library, with no way of extending that.

	- Godmar