X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
From: Rugxulo <rugxulo AT gmail DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: CC1.EXE/GCC.EXE crashes with SIGILL, hard.
Date: Mon, 26 Mar 2012 17:02:55 -0700 (PDT)
Organization: http://groups.google.com
Lines: 70
Message-ID: <963ed3e2-354f-48ce-90fd-43fb7263fe2d@v2g2000vbx.googlegroups.com>
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> <ed5d1b7e-15bd-4b9e-94f6-f2a1e1f91e90 AT em9g2000vbb DOT googlegroups DOT com>
NNTP-Posting-Host: 65.13.115.246
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-Trace: posting.google.com 1332806997 12619 127.0.0.1 (27 Mar 2012 00:09:57 GMT)
X-Complaints-To: groups-abuse AT google DOT com
NNTP-Posting-Date: Tue, 27 Mar 2012 00:09:57 +0000 (UTC)
Complaints-To: groups-abuse AT google DOT com
Injection-Info: v2g2000vbx.googlegroups.com; posting-host=65.13.115.246; posting-account=p5rsXQoAAAB8KPnVlgg9E_vlm2dvVhfO
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/534.16
 (KHTML, like Gecko) Chrome/10.0.630.0 Safari/534.16,gzip(gfe)
Bytes: 4585
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id q2R0F2Xu015155
Reply-To: djgpp AT delorie DOT com

Hi,

On Mar 20, 9:18 am, RayeR <gl DOT  DOT  DOT  AT centrum DOT cz> wrote:
>
> Does the testcase generate cmove even without
> __attribute__((__target__("sse"))) ?

No, I don't think it would help, though I haven't tried again since my
previous attempt.

> As I understand this attribude overrides the march=386 (attribute can
> affect compiler with many different ways so it should be used
> carefully) so it maybe correct and it's incorrect to hardcode
> __attribute__((__target__("sse"))) - should be made conditional? I
> don't know...

Unfortunately, I don't think it's that simple.

BTW, we've run into this problem before. Unfortunately, I think I'm
too green to do any good fixes or workarounds, at least not without
(more obvious) outside advice.

I still have an email from CWS from two years ago "saved" in my Inbox.
Let me quote it here:

>>> >I wish I was smart enough to make DJGPP (EMU387.DXE, perhaps?) emulate
>>> >the CMOV.. instructions.
>>>
>>> If you look at libc, and the interface to emu387, you could easily
>>> implement this (probably all from C). Contact me offline if you
>>> need technical assistance.
>>
>>I did look at it, but it was a bit over my head. It should be pretty
>>easy since the CMOV.. instructions (12?) have very similar / simple
>>encodings. (Note that I'm not referring to the FCMOV.. FPU
>>instructions, only the main vanilla ones.)
>
>1) find a machine that doesn't support CMOV
>2) run an application that uses CMOV
>3) note the signal number and other information in the traceback
>4) use signal() to establish a handler
>5) in the handler, check the exception state, which include EIP;
>   look at the instruction stream to see if the exception EIP is a
>  CMOV instruction
>6) If not, chain / exit handler.  If so, emulate.  You have a structure
>    with all the registers (writeable).  Emulate the not conditional
>    first, which is just adjust EIP and no actions required.

I don't have any experience with signal handlers (surprise surprise).
Though I did recently see something similar in DJGPP's uclock.c (trap
for RDTSC if necessary), so I guess it's not totally hard or
impossible.

My question to anybody reading is this:  Can you trap SIGILL in a
subprocess (spawned child .EXE) from a host parent .EXE? I doubt it,
but I'd be surprised to learn otherwise. In other words, how would you
even fix this? If you have to modify GCC and recompile, then it's
quite a boring chore and not so universal a fix. On the other hand,
hooking into EMU387.DXE (or similar) probably means some small runtime
tweaks anyways, so I don't know if that's totally painless either. I
guess a TSR might? be the "optimal" way to fix such a thing, but I
don't know.

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.

So, any better ideas or suggestions??   :-/