Since the control is transfered to VEX right after,
it is difficult to see except by activating internal
valgrind debug instrumentation, this way you'll have more assertion
on VEX generated code and more sanity checks activated.

I don't know all but i've found some assertion on
VEX generated code this way.

Kailash Sethuraman wrote:
As in when you make changes, if there are conflicts, make sure that my
change is not nuked. I think i did do some changes to m_translate.c .
Yes I am almost there at *$ecx, i have not seen that chunk of ASM code
yet. Though, will debug tonight.
I think we are pretty close, it might just be that the asm code is not
entirely Netbsd compat. lets see.


On 11/8/05, Eric Auge <[EMAIL PROTECTED]> wrote:


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


_______________________________________________
Vg4nbsd-devel mailing list
[email protected]
http://lists.berlios.de/mailman/listinfo/vg4nbsd-devel

Reply via email to