Mail Archives: djgpp-workers/2003/06/14/08:30:40
> Date: Sat, 14 Jun 2003 06:55:58 -0400
> From: CBFalconer <cbfalconer AT yahoo DOT com>
>
> The code from addvsi3 comes from the library, not from me.
Library, yes; but not the DJGPP library. It's from libgcc.a. That
library is part of the GCC distribution and supplied for every GCC
port to a CPU that doesn't have built-in support for 64-bit integer
operations.
I believe "gcc --help" cites a URL where one should report bugs.
Since you are the original reporter of the bug, I think it's best that
you report it there.
> The library failing is probably due to the gcc under which it was
> compiled.
I think it's rather due to the code of these routines. I don't have
time to look into the GCC source distribution and read the source code
of addvsi3 to verify that, though.
> It is not just overflows, it is raising signals in
> general. Compile something with "raise(SIGABRT);" and look at the
> code generated.
Merely raising SIGABRT should not produce any problems: in DJGPP,
SIGABRT _can_ be caught by a handler, and the handler _can_ return.
If the code after the call to `raise' supports such a situation,
everything will work as you'd expect. I just compiled a short test
program that raises SIGABRT and didn't see anything bad in the code it
generates after the call to `raise'.
So I don't understand what problem did you see in raising SIGABRT in
general.
> It is possible the problem is limited to use of SIGABRT, and that
> the prevention of return is deliberate.
I don't see in the generated code anything that prevents the handler
from returning. The code of addvsi3 does indeed prevent that, and the
code of `abort' does indeed exit if the call to `raise' returns, but
in general, there's nothing in GCC-generated code or in the DJGPP
library that prevents a SIGABRT handler from returning, provided that
the code that raises SIGABRT can cope with that.
> However integer overflow should not cause an abort willy-nilly.
> The application should be able to catch them.
Depending on what is the desired behavior, it might or might not be
possible to support it in the DPMI environment. Assuming that the
code of addvsi3 etc. is fixed in libgcc.a, it sounds like everything
else is ready for at least a minimal support of what you want.
> There is a mention
> (in signal.h) of "256 software interrupts + 32 exceptions = 288".
> I have no idea what exceptions are in this context, but it makes
> me suspicious that addvsi3 is doing something wrong, and that this
> is symptomatic.
Sorry, I don't see a connection between exceptions and what addvsi3
does.
The 32 exceptions mentioned in signal.h are the CPU exceptions such as
GPF, Page Fault, Invalid Opcode, etc. The DJGPP signal-handling
machinery converts them to signals (SIGSEGV, SIGILL, SIGFPE, etc.).
See dpmiexcp.c in the library for more details.
> At any rate I now know that I can use -ftrapv in development and
> catch silly errors. A better usage would be to generate INTO
> instructions with minimal impact on execution, provided INTO can
> be hooked for individual processes. And this goes deep into
> DOS/Wxx flavors, so there may be good reasons for the handling.
I think there's no easy way of supporting INTO in the DPMI
environment, but Charles should have the definitive answer to this.
Currently, the Overflow exception is converted to SIGFPE.
- Raw text -