Home Space
What does kb show for 64 bit processes?
I have recently made a mistake analyzing a callstack, because I didn't expect the application to be 64 bit. I have used the WinDbg command kb
to show the callstack and parameters passed to methods.
On 64 bit, the parameters are not passed via the stack but in registers (RCX, RDX, R8 and R9) instead. It seems that WinDbg has not or not fully implemented this. Partly I guess it is almost impossible since the register values might have changed meanwhile.
However, the WinDbg help still lists kb
as a valid command under User-Mode, x64 Processor
. Therefore my question is:
What does kb
display for 64 bit user mode processes? When/how is that output useful?
The "Args to Child" output shown in kb and kv in WinDbg has always been very suspect, even on the x86 those columns don't necessarily show you the arguments to the function.
On the x86, the "Args to Child" are simply [EBP+0x08], [EBP+0x0C], and [EBP+0x10] (kv shows four arguments, thus the last column is [EBP+0x14]). These will only be the arguments to the function if:
- The function uses an EBP frame
- The function has stack passed arguments (depends on the calling convention)
- The optimizer hasn't reused those locations for something else
On the x64, as you noted the first four arguments to the function are passed via registers. However, as part of the calling convention the caller is required to allocate "Home" (or "Spill") Space on the stack for each of these arguments. This space is always allocated, even if the called function takes fewer than four arguments. The called function is then free to use this Home Space any way it chooses, it may:
- Ignore it
- Save non-volatile registers there
- "Home" the register passed parameters onto the stack
The kb and kv output shows the Home Space in order (RCX Home, RDX Home, R8 Home, R9 Home). Most frequently this space will be used for 1 or 2 above, thus it won't actually have anything to do with the passed in arguments. However, in the Debug build the compiler immediately Homes the passed in arguments to make debugging easier.
For example, here's the prolog of a function with two arguments compiled Debug. Note the Homing of the arguments as the first instructions:
0:000> u DriverEntry
mov qword ptr [rsp+10h],rdx
mov qword ptr [rsp+8],rcx
push rdi
sub rsp,0C0h
And the same code compiled Release, using the Home Space for non-volatile register preservation:
0:000> u DriverEntry
mov qword ptr [rsp+8],rbx
mov qword ptr [rsp+10h],rdi
push rbp
lea rbp,[rsp-57h]
sub rsp,0B0h
This means the Home Space is usually pretty useless in terms of getting the arguments to the function. However, it can still be used as a debugging aid to reconstruct non-volatile register values on function entry (i.e. I can tell you the value of RBX or RDI above by looking at the Home Space)
南来地,北往的,上班的,下岗的,走过路过不要错过!
======================个性签名=====================
之前认为Apple 的iOS 设计的要比 Android 稳定,我错了吗?
下载的许多客户端程序/游戏程序,经常会Crash,是程序写的不好(内存泄漏?刚启动也会吗?)还是iOS本身的不稳定!!!
如果在Android手机中可以简单联接到ddms,就可以查看系统log,很容易看到程序为什么出错,在iPhone中如何得知呢?试试Organizer吧,分析一下Device logs,也许有用.
2 Answers
kb does list the stack back trace along with the three parameters, however it's the parameter passing mechanism (calling convention) which doesn't make the arguments displayed trustworthy. You must read more @ http://www.codemachine.com/article_x64deepdive.html
dv , and all other variants dv /v etc may all show garbage values. only in case of __this call we can use rcx as a this pointer but we must disassemble and ensure the pointer was not backed up somewhere else and then reused. Dis-assembly is the way to go unless we have homed parameters.