X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f NNTP-Posting-Date: Wed, 28 Mar 2012 20:26:18 -0500 From: "Charles Sandmann" Newsgroups: comp.os.msdos.djgpp References: <16777375 DOT 1302 DOT 1331688966231 DOT JavaMail DOT geo-discussion-forums AT vbat19> <4F60E096 DOT 2060106 AT iki DOT fi> <496fa848-de2c-4020-aced-ef298a0c5ec9 AT r21g2000yqa DOT googlegroups DOT com> <75057a79-95a3-41ec-93c6-8b459c4d9f9a AT h20g2000yqd DOT googlegroups DOT com> <963ed3e2-354f-48ce-90fd-43fb7263fe2d AT v2g2000vbx DOT googlegroups DOT com> Subject: Re: CC1.EXE/GCC.EXE crashes with SIGILL, hard. Date: Wed, 28 Mar 2012 20:26:03 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-RFC2646: Format=Flowed; Original Message-ID: Lines: 32 X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 64.91.136.221 X-Trace: sv3-rDvtxLtcSn5pC79R6jgm7fHgos52tkq/uINC6KrVpCdVAHhW8+tP3tZAex4/aNFGhT/9AW0h4Oj24wT!s3vUop9zlHMF1qElzzqNNvWIQAELXuB70l3pNfZxoOHD1LEtBdthIdhieIXuzwaMdT3XXW3OqKll!jMYVpQfnot3Q5J0FXBINsSYkQNAGfkiG X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 Bytes: 2963 X-Original-Bytes: 2902 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com >"Rugxulo" wrote in message >news:963ed3e2-354f-48ce-90fd->43fb7263fe2d AT v2g2000vbx DOT googlegroups DOT com... >My question to anybody reading is this: Can you trap SIGILL in a >subprocess (spawned child .EXE) from a host parent .EXE? Under DPMI 1.x, there is only one exception handler vector, so either a parent process can monitor what the child processess are doing, (or if the DPMI call hook isn't modified) a child can be the last-in hook to handle. This is how DJGPP debuggers work. >In other words, how would you even fix this? If you modify the library to monitor SIGILL and handle CMOV, that would be one way. You could also create a shell program (like redir) that hooked the right signals, then hooked some DPMI hooks to prevent the child from setting up it's own SIGILL handler. Catching and emulating will be slower. >A binary patch might also be feasible and at least a good short-term >ad hoc fix here, but CMOVxx is apparently smaller in opcode size than >the CMP / Jxx alternative, so that makes things trickier. And I have >not actively tried any of these methods (which is why I've delayed in >responding publicly), but some feedback is probably beneficial. There are ways to write binary patches that jump to a patch area, execute, then jump back, but this is more complex. Might be able to identify dead "noop" space to steal, but once again lots of code to write, test to "repair" a bug.