Date: Sat, 14 Jun 2003 15:27:21 +0300 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: djgpp-workers AT delorie DOT com Message-Id: <7048-Sat14Jun2003152720+0300-eliz@elta.co.il> X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9 In-reply-to: <3EEAFF3E.DB9719A7@yahoo.com> (message from CBFalconer on Sat, 14 Jun 2003 06:55:58 -0400) Subject: Re: Integer Overflow References: <3EEA9A4B DOT 7B15E2A AT yahoo DOT com> <4098-Sat14Jun2003113806+0300-eliz AT elta DOT co DOT il> <3EEAFF3E DOT DB9719A7 AT yahoo DOT com> Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > Date: Sat, 14 Jun 2003 06:55:58 -0400 > From: CBFalconer > > 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.