I verified that the d8 "callTachyonFFI" is effectively called when we are trying to call 'initHeap'. I also checked the machine code generated for 'initHeap' and there is no code generation issue. As said in a previous mail, iterating through the properties of an object when bootstrapped is not done in the same order as in v8. In initHeap it causes the fields of the context object to be initialized in a different order but the result is still good. As a reference, I include the IR before and after code generation and the code listing for both v8 and tachyon.
If I recapitulate, I verified the following: 1. The test for the bridge works, when calling C code from bootstrapped tachyon 2. When trying to call 'initHeap' from bootstrapped tachyon, the C callTachyonFFI is called 2. The 'initHeap' c proxy code listing is byte identical except for the move ordering issue 3. The 'initHeap' code listing is byte identical except for the initialization order of the context and the move ordering issue
I guess the only possibility left is that the proxy code is not calling the right function, which might happen if the linked value in the machine code block does not correspond to the address of the entry point of the function in memory.
Erick
Le 11-03-19 1:27 , chevalma@iro.umontreal.ca a écrit :
The code fails on "calling FFI with rawCallTachyonFFI". I see 2 possibilities from here:
- The pointer value for making the call is wrong
You should look into that. The function pointer points inside the machine code block.
- The generated code for callTachyonFFI is wrong
I tested this on its own in a unit test. It seems to work properly.
Maxime, could you take a look at this? The code used to test is now on the master branch and I am bootstrapping in 32 bits.
I will try a make bootstrap tomorrow if I have time.
- Maxime
Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list