I found the issue. The linked address was wrong because the base address was off by 6 which corresponds to the numerical value of undefined. In the bootstrapped getBlockAddr(blockObj, index), the index was never tested for undefined and in the linking code I was retrieving the address without an explicit index. I'll commit the fix.

We now get to compiling the stdlib but we run out of memory again.

Erick

Le 11-03-19 13:32 , Maxime Chevalier-Boisvert a écrit :

Well if the generated code is valid, that's good news. We should be pretty close to having it working. I suspect the same thing as you, that the linked values may be incorrect. The c proxy has the address of initHeap linked into it. It's also possible that whatever code gets the address of a given offset in the block gives the wrong result. I have implemented a separate getBlockAddr for Tachyon, so I should probably check that the result of that is correct. Finally, it's also possible the executable flag isn't set properly... Something I should look into as well.

- Maxime

On 11-03-19 12:43 PM, Erick Lavoie wrote:
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:
1. The pointer value for making the call is wrong

You should look into that. The function pointer points inside the machine
code block.

2. 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
_______________________________________________
Tachyon-list mailing list
Tachyon-list@iro.umontreal.ca
https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list
_______________________________________________
Tachyon-list mailing list
Tachyon-list@iro.umontreal.ca
https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list