DHooks x64 Linux enabler #2292
DHooks x64 Linux enabler #2292
Conversation
|
Seems like the tests are going to be failing until alliedmodders/metamod-source#212 is merged :( |
| if (m_vecArgTypes[i].custom_register == None) | ||
| { | ||
| // No matter what, the stack is allocated in slices of 8 bytes |
There was a problem hiding this comment.
How true does this hold for Linux ?
There was a problem hiding this comment.
Turns out to not be the case because (non-pointer trivial) objects can be passed inline on the stack which is really unfortunate.
There was a problem hiding this comment.
That's what I recalled reading, but I just wanted to make sure. As things stands right now, I'm doubtful the callconv implem is robust enough. You don't have/nor should you have to handle all cases, it's most likely going to look messy, but it's fine to just iterate m_vecArgTypes and just take them at face value (i.e we handle int, float, ptrs & vector, and we error by default if object/ref/or otherwise, because we don't know how to handle it)
| void x86_64SystemVDefault::SaveReturnValue(CRegisters* registers) | ||
| { | ||
| // It doesn't matter what the return value is, it will always be fitting on 8 bytes (or less) |
There was a problem hiding this comment.
That is definitively not true for SystemV, return value can get exploded on two registers.
There was a problem hiding this comment.
That is definitively not true for SystemV, return value can get exploded on two registers.
This should only matter in DHooks for ReturnType_Vector being split into XMM0/XMM1, right?
EDIT: Well, SourceHook != DHooks so I guess the pain remains...
There was a problem hiding this comment.
Given our present situation, yes it's not critical to handle all use-case. But it does need to be handled for vector return...
| // the actual underlining type does not matter |
There was a problem hiding this comment.
Ditto, there's more to investigate
|
I'll investigate more for those review comments |
Companion to alliedmodders/metamod-source#212
For
x86_64SystemVDefault.cpp, I copiedx86_64MicrosoftDefault.cppand then replaced things so you can see the diff in the second commit (link) on this branch.Currently includes the changes from #2290
TODO:
x86_64SystemVDefault.cpp