Comments (13)
Since we don't yet officially support Mac, and have no means to debug on Mac, you'll need to provide more information.
from angelscript-jit-compiler.
What kind of information could help? Does it work fine on 32-bit Linux?
[removedmy previous remark as it has nothing to do with the actual problem since this is all angelscript code, not native function calls]
from angelscript-jit-compiler.
After debugging and reading the JIT code a bit more, it seems that in the second half of the valueRegister is handled differently from the first, in 32-bit mode: on a RET instruction, only the first half is set (using pbx), while the other half was set previously, during the asBC_CpyVtoR8 instruction. So I am guessing that the second half of the value register is erased by instructions in between (maybe the release call?). But I have not found where yet...
By the way, is it possible to dump the generated assembly code for a JIT function?
Code example:
class T {double Value(){return 5.2;}}; T t; double main(){ return t.Value();}
Generated bytecode: something is probably happening to the second half of the value register during calls 13 or 15 in the JIT function.
double T::Value()
Temps: 2
Variables:
000: T this
0 2 * JitEntry 0
2 2 * PshVPtr v0
3 3 * CALLSYS 2 (void _builtin_object_::_beh_5_())
5 2 * JitEntry 0
1,25
7 2 * JitEntry 0
9 2 * SetV8 v2, 0x4014cccccccccccd (i:4617540697942969549, f:5.2)
12 2 * {
12 2 * }
12 2 * CpyVtoR8 v2
13 2 * 0:
13 2 * FREE v0, 8720560
15 2 * RET 1
double main()
Temps: 2
Variables:
0 2 * JitEntry 0
1,60
2 2 * JitEntry 0
4 2 * PshGPtr 4717696
6 3 * CHKREF
7 3 * CALLINTF 113 (double T::Value())
9 2 * JitEntry 0
11 2 * CpyRtoV8 v2
12 2 * {
12 2 * }
12 2 * CpyVtoR8 v2
13 2 * 0:
13 2 * RET 0
from angelscript-jit-compiler.
I can actually confirm that it is the call to FREE that messes up the register: commenting it in the JIT makes the returned value ok.
from angelscript-jit-compiler.
Pushed what I think is a fix for this. AngelScript normally discards return values at those locations, which I broke with the refcounting change. I think it should be working for you now.
from angelscript-jit-compiler.
Thanks for pushing a fix so quickly! Unfortunately, the issue is still here. After further analysis, the FREE instruction (to release the object) ends in call_viaAS() to call the release function, because it is an ICC_VIRTUAL_THISCALL. So either the problem comes from the CallSystemFunction in angelscript itself, or it is not called with the appropriate arguments, so the value register is modified whereas it should not (or maybe the value register should be actually set AFTER, when the RET instruction is called?). Still investigating...
from angelscript-jit-compiler.
I think I forgot to change call_viaAS.
from angelscript-jit-compiler.
Is it fixed now?
from angelscript-jit-compiler.
No, but I think I have found the root cause. If I understand well, your patch fixes the fact that registers may be modified by copying data from the value register when it is not needed. Whereas the problem here is just that the value register is modified by the angelscript engine (and that's the value register that is used to return the value, and it was set before calling the release method thru the AS engine).
I have noticed that when the function called does not return anything, the angelscript engine wrongly erases the value register with random values. It is easy to fix using the following patch:
--- angelscript/source/as_callfunc.cpp (AS 2.29 WIP)
+++ angelscript/source/as_callfunc.cpp (working copy)
@@ -672,7 +672,7 @@
*(asDWORD*)&context->m_regs.valueRegister = (asDWORD)retQW;
#endif
}
- else
+ else if( sysFunc->hostReturnSize == 2 )
context->m_regs.valueRegister = retQW;
}
However I am wondering if it would not be safer to modify the JIT too, so that when returning a 64-bit value, the value register is properly set AFTER the call to the FREE instruction (in the RET instruction). Today, only half of it is set at this stage:
//Update value register
as<void*>(*ebp+offsetof(asSVMRegisters,valueRegister)) = pbx;
What do you think? Please disregard my comment above if this is nonsense, as I am a complete assembly/JIT compiler beginner...
from angelscript-jit-compiler.
Though it would be more correct for AngelScript not to touch the value register if there is no return, it is still valid for these functions to return something that would write to the register. AngelScript would normally save the value of the register across the call, so that's the only proper way to fix it in the JIT.
from angelscript-jit-compiler.
I agree that it would indeed be safer to really fix it in the JIT, but I don't know how to do it properly... Where is the second half of the value stored (first half is in pbx)?
from angelscript-jit-compiler.
Just put up the fix.
from angelscript-jit-compiler.
Wonderful, thanks! You rule! It indeed fixes the issue, even when the AS engine overwrites the register. Great job!
At least, this issue has enabled me to understand a bit better how the JIT works :-).
from angelscript-jit-compiler.
Related Issues (20)
- angelscript v2.28 support? HOT 1
- Version compatibility? HOT 1
- valgrind detects invalid write in virtual_asm.h HOT 4
- int64 issue HOT 2
- "Short jump too long." exception in msvc x64 project without JIT_FAST_REFCOUNT flag HOT 4
- shift int64 right HOT 5
- formatInt from scriptstdstring add-on crashes with Jit HOT 5
- AS 2.3 Support HOT 4
- Suspend Bug
- asBC_POW x86_64 issue HOT 1
- Warning C4267
- AngelScript wiith JIT: calling function of the POD type corrputs stack HOT 2
- Random crash with variable passed locally HOT 8
- decomplie byte code to src supported? HOT 1
- Argument clobbering & bad return value for DoesReturnOnStack HOT 1
- Any chance this will get updated for newer AngelScript versions?
- crash on OSX 32-bit when using asCALL_THISCALL_ASGLOBAL HOT 8
- crash with object handles if not using JIT_FAST_REFCOUNT HOT 1
- Exception thrown on OSX / 64-bit if not using JIT_FAST_REFCOUNT HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from angelscript-jit-compiler.