The application crashes consistently with one of the fence usage.
I have added a special handler for lock based fences to the prefix
handling "while" block in disInstr_X86_WRK (VEX/priv/guest_x86_toIR.c).
This seems to fix the crashes and the application runs fine.
Since all of the machines this application will run on are P4 or above,
translating the lock based fence to a mfence is fine.
Can anyone help assert if this is a sensible thing to do.
case 0xF0: {
{
UChar* code = (UChar*)(guest_code + delta);
/* standard form - F08344240000: lock addl $0, 0(%esp)
* our version - F0834424FC00: lock addl $0, (-4)(%esp
if (code[0] == 0xF0 && code[1] == 0x83 && code[2] == 0x44 &&
code[3] == 0x24 && code[4] == 0xFC && code[5] == 0x00) {
delta += 6;
stmt( IRStmt_MBE(Imbe_Fence) );
goto decode_success;
}
}
pfx_lock = True;
*expect_CAS = True;
break;
}
Thanks,
Madhan.
On Fri, Aug 7, 2009 at 11:46 AM, Madhan Sadasivam <[email protected]>wrote:
> Hello,
>
> To work with PIII machines my applications performs a fence
> using the following assembly code.
>
> lock; addl $0, (-4)(%%esp)
>
> During Valgrind 3.2.3 times, looking at, VEX/priv/guest-x86/toIR.c,
> I guess a fence instruction is explicitly emitted.
>
> Can you please tell me how this happens in 3.5.0 code line.
> We use (-4) instead of (0) as this hinders with a different feature.
> So I may need to modify Valgrind to also recognize (-4).
> The instruction looks like this "f0 83 44 24 fc 00"
> instead of "f0 83 44 24 00 00"
>
> Thanks,
> Madhan.
>
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
