Closed 0x161e-swei closed 6 months ago
Ha, that is correct! Somehow, the R
part is missing from some of the CALL
instructions. Will get back with a fix soon.
Thanks for pointing this out!
Pushed a fix for this - it is available in the following commit: https://github.com/bitdefender/bddisasm/commit/3df189f093151c0cc60fe7b1a5818ced7b9189e8
Thanks again for reporting this!
Hi @vlutas Thanks a ton for the quick fix!
Upon closer inspection, I saw that syscall
did not read from Rip, sysexit
did not read from Rcx and Rdx.
Could you please fix these as well?
Hello! You are right, thanks for pointing this out as well. This should also be fixed with the latest commit. Out of curiosity - what are you using bddisasm for? Generally, not very many people are interested in so deep details about the instructions operands & functionality. Thanks again for reporting this!
Hi @vlutas, thanks for sending in the fixes. I am trying to use bddisasm for decoding Intel PT traces for microarchitectural simulation in Champsim.
Hi @vlutas, sorry for keeping pinning in this thread. I found that the "IRET" class of instructions are missing RW accesses to rSP?
Hello!
That is actually intended. The point is that rSP
and SS
are only modified when doing an IRET to a different privilege level, and we cannot check that from BDDISASM. Due to this, we only store those operands that are guaranteed to be accessed.
I tried decode instruction
ff d0
with theNdDecodeEx(&ix,...)
function and it gavecall rax
.However, the
ix.RipAccess
feild is set with only 0x2 andix.StackAccess
set to 0x2.Since the call instructions should store the call-site onto the stack, should
ix.RipAccess
be0x2 | 0x1
?ND_ACCESS_WRITE
is defined as 0x2 andND_ACCESS_READ
is 0x1.