|
From: Gert W. <gw....@gm...> - 2010-01-21 11:14:39
|
Hi all, I'd like to work on bug https://bugs.kde.org/show_bug.cgi?id=180217 vex amd64->IR: unhandled instruction bytes: 0xF3 0x48 0xF 0xBD 0xC0 0x4C I've had a look at the valgrind 3.5.0 code base, and I got some idea where I would have to fix this in guest_amd64_toIR.c As far as I can tell, this hasn't been addressed yet in the svn, right? However, I guess I could create the needed test cases and edit the part where the instruction is identified, but from there on I have currently no idea, how to implement the required dis_LZCNT_bla function. Is there some kind of documentation I can read to understand how things are done or could you suggest a function that I could use as a blueprint? Many thanks, Gert |
|
From: Filipe C. <fi...@gm...> - 2010-01-21 16:23:48
|
Hi! The source code is fairly easy to understand (and if you have any doubts, there's always the mailing list ;-) ). Start reading in guest_amd64_toIR.c, line 16206: DisResult disInstr_AMD64 ( ... This function disassembles an AMD64 instruction. Mainly it checks some stuff and calls disInstr_AMD64_WRK, which is the function you're interested in. Understand the control flow: Checking, prefixes, instructions, finalizing. I don't know if that is also a valid Intel instruction... But if it's not, you "just" have to follow the control flow and place the appropriate instructions to deal with it. You'll have to look at the IR in order to see if it already has an instruction for that and, if not, how to implement it using what you have. Best of luck, F On 1/21/10 11:08, Gert Wollny wrote: > Hi all, > > I'd like to work on bug https://bugs.kde.org/show_bug.cgi?id=180217 > vex amd64->IR: unhandled instruction bytes: 0xF3 0x48 0xF 0xBD 0xC0 0x4C > > I've had a look at the valgrind 3.5.0 code base, and I got some idea > where I would have to fix this in guest_amd64_toIR.c > As far as I can tell, this hasn't been addressed yet in the svn, right? > > However, I guess I could create the needed test cases and edit the part > where the instruction is identified, but from there on I have currently > no idea, how to implement > the required dis_LZCNT_bla function. > Is there some kind of documentation I can read to understand how things > are done or could you suggest a function that I could use as a blueprint? > > Many thanks, > > Gert > > > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for Conference > attendees to learn about information security's most important issues through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > > > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Gert W. <gw....@gm...> - 2010-01-21 22:20:15
Attachments:
VEX-amd64-lzcnt.patch
valgrind-amd64-lzcnt.patch
|
lzcntw r16.uw[0x0468] r16.uw[0] => 1.uw[5] lzcntw m16.uw[0x2642] r16.uw[0] => 1.uw[2] lzcntw r16.uw[0x0000] r16.uw[0] => 1.uw[16] lzcntw r16.uw[0x8000] r16.uw[0] => 1.uw[0] lzcntl r32.ud[0x00072468] r32.ud[0] => 1.ud[13] lzcntl m32.ud[0x75318642] r32.ud[0] => 1.ud[1] lzcntl r32.ud[0x00000000] r32.ud[0] => 1.ud[32] lzcntl r32.ud[0x80000000] r32.ud[0] => 1.ud[0] lzcntq r64.uq[0x1357246813572468] r64.uq[0] => 1.uq[3] lzcntq m64.uq[0x8531864275318642] r64.uq[0] => 1.uq[0] lzcntq m64.uq[0x7531864275318642] r64.uq[0] => 1.uq[1] lzcntq r64.uq[0x0000000000000000] r64.uq[0] => 1.uq[64] |
|
From: Filipe C. <fi...@gm...> - 2010-01-22 14:15:21
|
Hi!
On 1/21/10 22:20, Gert Wollny wrote:
> Hello!
>
> 2010/1/21 Filipe Cabecinhas <fi...@gm... <mailto:fi...@gm...>>
>
> The source code is fairly easy to understand (and if you have any
> doubts, there's always the mailing list ;-) ).
>
> Indeed, it was really quite easy to get going. I did implement LZCNT in
> terms of BSR, and it now passes some basic tests, so it's a point to
> start from.
> There's one thing though, how can I test that the flags are properly set?
Check memcheck/tests/x86/more_x86_fp.c
The tests for CMOV inspect the eflags value (by executing a gcc asm block).
> I guess creating an IR would be the next step. Where would I add the
> opcode enum? - just at the end of the big list?
>
> Okay, I've attached the patches against valgrind aand VEX and the test
> definition file. Any pointer how to improve this are very welcome.
>
I don't think you need to create a new IR instruction. I suppose using
BSR is okay (but hey... I'm no valgrind expert... You can always wait
for Julian's (or another person's) reply, if you want a definitive
answer ;-) )
But, in your code, where you have:
---------------------------------
+ if (haveF2orF3(pfx)) {
+ if (haveF3(pfx))
+ delta = dis_LZCNT ( vbi, pfx, sz, delta );
+ else
+ goto decode_failure;
+ }else
---------------------------------
But you're testing against F3 twice. I would change that to:
if (haveF3(pfx)) {
delta = dis_LZCNT ( vbi, pfx, sz, delta );
else if (haveF2(pfx))
goto decode_failure;
else ...
The patch seems okay but I can't test it... Haven't got the hardware for
it and gcc doesn't compile it in macosx.
Regards,
Filipe
|
|
From: Gert W. <gw....@gm...> - 2010-01-23 01:21:41
|
> > Hi!, > > The tests for CMOV inspect the eflags value (by executing a gcc asm block). I was hoping there's already something pre-made, like with the other tests, now I have to brush up my knowledge in assembler ;) The patch seems okay but I can't test it... Haven't got the hardware for it > and gcc doesn't compile it in macosx. > Well, the carry flag was not set properly, and I will attach a(nother) unified patch to the bug report tomorrow. There were at least two people who came across the problem and have the hardware and probably watch the report. Best, Gert |