This is the mail archive of the java-discuss@sourceware.cygnus.com mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

question about arithmetic exceptions



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?  (In fact, from looking at 
egcs/gcc/Makefile.in, it seems as though only the eh portion is
given the -fexceptions flag.)

I could imagine that people didn't want the exception information
in C executables that don't make any use of them.  Nevertheless,
the hack in libgcj seems suboptimal.

As an aside, I find the way libgcc.a is built rather strange.
Does anybody know the motivation and/or history behind this highly 
unusual setup?

	- Godmar


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]