32-bit Context can't interact with the FPU registers in 32-bit apps

[alphayellow1]

It would be interesting to add this functionality, since directly accessing loaded values into the FPU registers from ST(0) until ST(7) is required sometimes for older 32-bit applications. Thanks.

[angelfor3v3r]

Shouldn't be too bad, I think. We'll have to add it to the Context struct and rewrite mid_hook.x86_32.asm to support it.

[ThirteenAG]

Shouldn't be too bad, I think. We'll have to add it to the Context struct and rewrite mid_hook.x86_32.asm to support it.

Do you have anything concrete in mind? Asking because I'm not sure how to deal with all possible usage scenarios, e.g.

.text:00B5E575 D9 EE                                                           fldz
.text:00B5E577 D9 EE                                                           fldz
.text:00B5E579 D9 EE                                                           fldz
.text:00B5E57B D9 EE                                                           fldz

void test(SafetyHookContext& ctx) {
  _asm fldz
  _asm fldz
  _asm fldz
  _asm fldz
}

nop(0x0xB5E575, 4*2);
g_hook = safetyhook::create_mid(0xB5E575, test);

Currently this would work, but what would ctx variable have for this sort of thing? Especially when there's many more instructions like fst, fstp, etc.

[alphayellow1]

Couldn't FXSAVE/FXSAVE64 and FXRSTOR/FXRSTOR64 be used to save and restore the x87 FPU and XMM states? It stores their state in a 512 byte area in memory, then reserving that space at the top of the midhook ASM, passing the registers' state to the callback and then restore the registers afterwards.

[angelfor3v3r]

I've brought up those instructions years ago and was looking at things like GetThreadContext in Win32 and such, but I think we did it by hand just to be safe from any weirdness that may happen across CPUs. Still, we could give it a try someday maybe. I'll mess around in the near future maybe once other things are settled down in the PRs.

[ThirteenAG]

Don't know if useful, but my real use cases usually look like:

float t = 0.0087266462f;
float f = 0.0f;
_asm {fstp[f]}
f = AdjustFOV(f, Screen.fAspectRatio);
_asm {fld[f]}
_asm {fmul[t]}

_asm {fld  dword ptr[x]}
_asm {fadd dword ptr[f]}

float fTweakFOV = 1.05f;
float fAspectRatio = (SCREEN_WIDTH / SCREEN_HEIGHT);
float result = fTweakFOV * fAspectRatio;
_asm {fld dword ptr[result]}

void Find3rdPersonCamTargetVectorFMUL(SafetyHookContext& ctx)
{
    float f = CDraw::GetAspectRatio();
    _asm {fmul dword ptr[f]}
}

[angelfor3v3r]

@ThirteenAG I'll have a PR ready to go soon if you want to test it. I don't know if it works in real cases but it has some tests and stuff. I'll let you know, but please let me know if theres any issues or additions that would be needed. I know I missed some stuff like FPU Control words and such, but I don't know when people will need those.

[ThirteenAG]

Sure, I'll take a look.

[angelfor3v3r]

Alright, I have #127 there now. This is extremely experimental and I get nervous doing anything with the midhook code. Let me know how it goes.

[angelfor3v3r]

Made some edits at 8916e64 if you don't mind trying it out @ThirteenAG

I really don't like some of this code but let's see how it goes.

Thank you for helping!

[ThirteenAG]

I will check on the actual code later, have some questions in the meantime.
So, I think I understand the proposed usage for get/set values on the fpu stack, but what about push and pop?

E.g. this

void Find3rdPersonCamTargetVectorFMUL(SafetyHookContext& ctx)
{
    float f = CDraw::GetAspectRatio();
    _asm {fmul dword ptr[f]}
}

would/should become

void Find3rdPersonCamTargetVectorFMUL(SafetyHookContext& ctx)
{
    float f = CDraw::GetAspectRatio();
    ctx.st0 *= f; //_asm {fmul dword ptr[f]}
}

but what if it needs fmulp for example?
I believe in that case it can be something like

void Find3rdPersonCamTargetVectorFMUL(SafetyHookContext& ctx)
{
    float f = CDraw::GetAspectRatio();
    ctx.st1 = ctx.st0 * f;
}

if I'm not mistaken, but I don't know enough how original instructions affect stack pointer and whatnot. Would that just work like that?

[angelfor3v3r]

This all gets very confusing and I don't have too much knowledge with this stuff but the PR I made only lets you write to fixed slots, it doesn't allow you to push/pop or do stack manipulation.

Wit the API I wrote, I think it would probably become:

void Find3rdPersonCamTargetVectorFMUL(SafetyHookContext& ctx)
{
    float f = CDraw::GetAspectRatio();
    ctx.st0.set_f32(ctx.st0.as_f32() * f);
}

Basically, you must compute the result and write it to the correct slot yourself. The status words aren't available, but maybe I could add them (fstsw/fldsw or fnstenv/fldenv or something).

These would most likely be read-only(?), and let you see what slots are used and probably other crazy stuff I don't even know about.

[ThirteenAG]

My primary concern is that if there's no way to replicate a certain instruction sequence, all inline asm usage will be overwritten by ; restore context part of the hook after. Or am I wrong about this?

[angelfor3v3r]

I think you might be right. You probably shouldn't use inline asm to modify x87 stuff in here and prefer to use safetyhook, if im understanding right.

I see some other bugs that might be really bad, like the lack of the FPU environment being saved/restored and stuff.

This is such a headache and I don't even know if it's feasible or stable. I'm starting to really consider FXSAVE at this point or something, even if it will make the struct a few hundred bytes bigger.

[ThirteenAG]

Yeah, it's much more confusing to me than xmm usage. Slightly easier example:

addr1    fld [var1]
addr2    fstp [var2]

nop(addr2); //disabling original fstp instruction to overwrite var2 inside the hook
g_hook = safetyhook::create_mid(addr2, test);

void test(SafetyHookContext& ctx) {
 //with the released version would just use inline asm
 //_asm  fstp [var2]

 //to avoid inline asm, need to do
 var2 = ctx.st0;
}

since there's no fstp opcode involved, fpu stack will be corrupted, because

FSTP Operation

DEST := ST(0);
IF Instruction = FSTP
    THEN
        PopRegisterStack;
FI;

since there's no PopRegisterStack operation.

I see two ways to go about this, either figure out how to handle such cases(if it's even possible), or avoid saving and restoring fpu stack, so you essentially can avoid inline asm in some cases, and use inline asm in other cases where needed.

[angelfor3v3r]

I think it might be possible to add stack stuff if I switch over to fxsave or something. It's definitely getting annoying and I don't know whats "correct" or not. 😅