Kailash Sethuraman wrote:
Sweet, looking forward to see it, I made new commits yesterday, with
debugging info added in. Helps us know how far we have got and where
exactly the error is, as development is not consistently going on at
the moment. when you commit vex, please do ensure that the changes
dont back out each other.
"dont back out each other" sorry my weak english don't understand.
Looking forward to the new vex :)
heheh hopefully it will work.
Hopefully that will fix our problems.
I was debugging run_innerloop asm before I slept off at some point.
I hope you will reach the same point I reached sometime ago
first the call *$ecx and then discovering that it is within
VEX generated code...
The problem here is the VEX generated code is not _obvious_ (i mean
it's hard already when it's obvious :) to debug, at least to me :)
we will succeed making a hello_world that return 0; only run through valgrind :)
Regards,
Eric.
Regards,
Kailash
On 11/8/05, Eric Auge <[EMAIL PROTECTED]> wrote:
Hello,
FYI VEX seems to be on the "good" way, still some issue in
m_translate.c and some other places, but they doesn't
look like big blocking issues :)
I was unable to finish yesterday night,
I hope to finish tonight.
see ya guys,
Regards,
Eric
NB:
01:23AM <hsaliak> eh run_innerloop is pushing registers into stack
01:24AM <hsaliak> doh nevermidn
01:25AM <hsaliak> l8r
01:25AM <hsaliak> we should discuss on ML more
<spoty> yes
<spoty> run_innerloop is pusshin register on the stack
<spoty> because that's what require VEX
<spoty> it is doing the VEX exec environnement setup
<spoty> iirc
_______________________________________________
Vg4nbsd-devel mailing list
[email protected]
http://lists.berlios.de/mailman/listinfo/vg4nbsd-devel
_______________________________________________
Vg4nbsd-devel mailing list
[email protected]
http://lists.berlios.de/mailman/listinfo/vg4nbsd-devel
