Mail Archives: djgpp-workers/2000/05/03/03:59:44
>> For instance if you take GNU make Version 3.77
>> and run from it a program that raises such an exception
>> then its make itself that crashes with a SIGFPE !!
>
>This probably means that we need to augment Make with special
>treatment for SIGFPE when it invokes child programs. Thanks for
>pointing this out.
Yes, that was my idea !
>> If "make" would hook the interrupt 0x31 and remember addresses of the
>> child
>> interrupt 0x75 handlers it could redirect the exception on the basis
>> of the selector part of the exception address in the FPU
>> (basically trying to rectify the wrong behavior of WinXX !)
>
>Oh, you want the parent to lcall the child's exception handler, like
>dbgcomm.c does, yes? I don't think this will work. By the time the
>parent program receives the FP exception, the child already exited.
>So you cannot lcall it, because it's not there: its memory was
>released, its descriptors were deallocated, etc. You will be jumping
>into the Great Void...
If we wait for the exception created by the djgpp_npx_hdlr it will be
too late,
I agree here ! So the only way to solve this would be to handle it directly
inside the
interrupt handler !!
So before calling the sub process we should :
intercept interrupt 0x31 to get the interrupt 0x75 address changes
set a special interrupt 0x75 handler that will call the
correct registered interrupt handler based on the value of the address
selector in the npx.cs field of FPU !
Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller AT ics DOT u-strasbg DOT fr
Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99
- Raw text -