Advanced Debugging
About AdvDbg Consult Train Services Products Tools Community Contact  
欢迎光临 高端调试 登录 | 注册 | FAQ
 
  ACPI调试
Linux内核调试
Windows内核调试
 
  调试战役
调试原理
新工具观察
 
  Linux
Windows Vista
Windows
 
  Linux驱动
WDF
WDM
 
  PCI Express
PCI/PCI-X
USB
无线通信协议
 
  64位CPU
ARM
IA-32
  CPU Info Center
 
  ACPI标准
系统认证
Desktop
服务器
 
  Embedded Linux
嵌入式开发工具
VxWorks
WinCE
嵌入式Windows
 
  格蠹调试套件(GDK)
  格蠹学院
  小朱书店
  老雷的微博
  《软件调试》
  《格蠹汇编》
  《软件调试(第二版)》
沪ICP备11027180号-1

C/C++本地代码调试

帖子发起人: william   发起时间: 2009-09-18 11:24 上午   回复: 5

Print Search
帖子排序:    
   2009-09-18, 11:24 上午
william_ai 离线,最后访问时间: 2009/6/1 21:39:01 william

发帖数前75位
注册: 2009-06-01
发 贴: 14
大家来讨论一下64位程序dump分析的一些问题
Reply Quote
相信分析过AMD x64位dump的人都知道,比起32位来困难多了,首先函数调用的前4个参数,是通过RCX,RDX,R8,R9寄存器传递的,这样很难从栈里把参数恢复过来,不知道各位有什么高招没有。
还有一个问题就是优化后的Release版,用KD或DDS命令看原始栈,可以看到很多已经执行完的函数还在栈里,停留在函数最后一个}这一行,实在是搞不懂为什么会这样。
另外一个问题就是ebp寄存器完全不靠谱,和问win2完全不一样。例如在我的一个dump里就出现了这样的情况。
00000000`1cf06c28  6a96b368 utilDebug!LogAdaptor::AdjustLogIfChanged+0x288 [utildebug\dbg_ns_debug.cpp @ 143]   //143行正是AdjustLogIfChanged()的最后一个}
00000000`1cf06c2c  00000000
00000000`1cf06c30  6a97cc50 utilDebug!g_LogAdaptor
00000000`1cf06c34  00000000
00000000`1cf06c38  00000000
00000000`1cf06c3c  00000000
00000000`1cf06c40  3e710901
00000000`1cf06c44  00000000
00000000`1cf06c48  6a96b368 utilDebug!LogAdaptor::AdjustLogIfChanged+0x288 [utildebug\dbg_ns_debug.cpp @ 143]
00000000`1cf06c4c  00000000
00000000`1cf06c50  6a97cc50 utilDebug!g_LogAdaptor
00000000`1cf06c54  00000000
00000000`1cf06c58  00000000
00000000`1cf06c5c  00000000
00000000`1cf06c60  6ac6c2b8 cfgSmexSettings!`string'
00000000`1cf06c64  00000000
00000000`1cf06c68  6a96b368 utilDebug!LogAdaptor::AdjustLogIfChanged+0x288 [utildebug\dbg_ns_debug.cpp @ 143]
00000000`1cf06c6c  00000000
00000000`1cf06c70  6a97cc50 utilDebug!g_LogAdaptor
00000000`1cf06c74  00000000
首先这个函数绝对不是递归调用的,按理来说函数调用完成后,应该从栈里清理掉了

用!teb命令,看到栈的信息:
TEB at 000007ffffef0000
    ExceptionList:        0000000000000000
    StackBase:            000000001cf20000
    StackLimit:           000000001cef9000
而ebp的值是  
0:015> r ebp
Last set context:
ebp=3e1fad00
0:015> r esp
Last set context:
esp=1cf1f6d8
刚开始怀疑是ebp寄存器的值被破坏了,后来用windbg挂到一个正常执行的程序上去,发现ebp也是这种情况。


IP 地址: 已记录   报告
   2009-09-18, 23:00 下午
william_ai 离线,最后访问时间: 2009/6/1 21:39:01 william

发帖数前75位
注册: 2009-06-01
发 贴: 14
Re: 大家来讨论一下64位程序dump分析的一些问题
Reply Quote
另外发现一个问题,就是在64位多核的机器上,程序多次崩溃在 ofstream和owstringstream的构造函数中,尤其是owstringsteam的构造函数崩溃更是不可思议,就是owstringstream oss这样普通的语句,crash点在msvcp80, 不知道是根据windbg dump分析定位有问题还是msvcp80.dll本身真的有问题,不知道有没人碰到过类似的问题。

IP 地址: 已记录   报告
   2010-04-11, 09:42 上午
jiayiw 离线,最后访问时间: 2009/2/16 11:16:16 jiayiw

发帖数前500位
注册: 2009-02-16
发 贴: 2
Smile [:)] Re: 大家来讨论一下64位程序dump分析的一些问题
Reply Quote
对于64位的dump分析,如果是优化过的代码,确实是没有办法从stack上面的到参数,但是有一个编译器选项可以把参数放到Home Space上面去,这样仍然可以从stack上面的到我们需要的参数。 微软最新的程序也开始使用这个选择开始编译,所以,痛苦会越来越少。

另外,如果真的是/Ox 编译的,我们也可以通过ub来获得相应的参数,因为我们知道他的前四个参数肯定是通过rcx,rdx, r8,r9 来传递的。

您上面的stack结果是通过什么得到的?k or dps/dds?


IP 地址: 已记录   报告
   2010-04-11, 09:48 上午
jiayiw 离线,最后访问时间: 2009/2/16 11:16:16 jiayiw

发帖数前500位
注册: 2009-02-16
发 贴: 2
Re: 大家来讨论一下64位程序dump分析的一些问题
Reply Quote
一篇好文章:
http://blogs.msdn.com/ntdebugging/archive/2009/01/09/challenges-of-debugging-optimized-x64-code.aspx
IP 地址: 已记录   报告
   2010-04-11, 18:31 下午
WANGyu 离线,最后访问时间: 2012/9/10 3:34:00 王宇

发帖数前10位
男
注册: 2007-05-08
发 贴: 306
Re: 大家来讨论一下64位程序dump分析的一些问题
Reply Quote
粗看了一眼确实是好文章,最近正好要移植一个驱动到x64 平台,晚上再仔细阅读一下!
IP 地址: 已记录   报告
   2010-04-20, 20:50 下午
WANGyu 离线,最后访问时间: 2012/9/10 3:34:00 王宇

发帖数前10位
男
注册: 2007-05-08
发 贴: 306
Re: 大家来讨论一下64位程序dump分析的一些问题
Reply Quote
已经移植了好几个小玩意到x64平台了,还是挺好玩的,呵呵,现在就等公司把驱动签名买回来了。
IP 地址: 已记录   报告
高端调试 » 软件调试 » C/C++本地代码调试 » Re: 大家来讨论一下64位程序dump分析的一些问题

 
Legal Notice Privacy Statement Corporate Governance Corporate Governance
(C)2004-2020 ADVDBG.ORG All Rights Reserved.