Mail Archives: djgpp/2012/03/26/20:15:18
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?? :-/
- Raw text -