MSDN Magazine - December 2008 - (Page 109)

Kenny Kerr WindoWs With C++ x64 Debugging With Pseudo Variables And Format Specifiers For many years, Visual C++ has included a set of pseudo variables and format specifiers for use in debugging. By pseudo variables I mean terms that you can enter into a debugger watch window to have it display some value that doesn’t necessarily relate to any C++ variable. Unfortunately, pseudo variables have never been well documented. Although I don’t have enough insider information to document them myself, I want to share some of the pseudo variables and format specifiers that I’ve found most useful. I hope the discussion will inspire you to read up on the subject. Before I introduce pseudo variables (which are sometimes called pseudo registers), I need to say a word about processor architectures and registers, because a little bit of background can make pseudo variables a lot more valuable. It will also help you understand one way the 64-bit versions of your application differ from traditional 32-bit applications. As this column is more about Visual C++ than about the smallest details of processor architecture, I’m going to limit this discussion to the x86 and x64 processor architectures. You can learn more about the differences introduced by the Itanium processor by reading the documentation in the MSDN library. Processor architectures aren’t very easy for mere mortals to fully comprehend. Processor Architectures Processor architectures aren’t very easy for mere mortals to fully comprehend. That’s why the C language and its successors made such an impact on the software industry. At the very least, you should have an idea of what the x86 and x64 processor architectures represent, as they are the processors the vast majority of users own. Windows and Visual C++ also support the Itanium processor, but very few developers have the luxury of targeting it. For better or worse, x86 has dominated over the last few decades with its roots in the 8-bit Intel 8080 processor. AMD and Intel made a pragmatic choice with x64 in order to retain backward compatibility with x86. Itanium, on the other hand, introduced a powerful new architecture that isn’t restricted by the legacy of x86. Of course, far fewer applications are supported as a result, but it is a testament to David Cutler (who led the development of Windows NT) and his vision of a portable operating system that Windows has been able to adopt new architectures so relatively painlessly over the years. Although many of the differences between the processor ar- chitectures are hidden behind the C++ compiler, one that developers can clearly see a benefit from is the move to a single calling convention. The x64 version of the C++ compiler only supports a single calling convention, whereas the x86 compiler supports a handful. This is a welcome change, as it eliminates many of the potential bugs introduced by a mismatch of calling conventions, particularly in managed code interop where the Microsoft .NET Framework compilers, such as C# and Visual Basic .NET, cannot check the original calling conventions in the C++ header files. Instead, they must rely on handcrafted attributes, which can easily be defined incorrectly, leading to various stack corruption bugs. The ecx register, for example, is used by the native C++ calling convention, known as thiscall, to store the “this” pointer before a member function is called. This knowledge is useful for debugging but is dependent on the calling convention, which may not be obvious just by looking at some assembler code and register values. This is far simpler on x64 as the “this” pointer is always inserted as the first parameter and thus stored in the rcx register. Naturally, using registers in debugging is very processor specific, but fortunately the relationship between x86 and x64 can be exploited. The x86 architecture introduced the concept of sub-registers where a sub-register consisted of the lower half of its super-register. For example, ax is a 16-bit sub-register consisting of the lower half of the eax register. The x64 architecture extends this by providing 64-bit registers that supersede the 32-bit x86 registers. For example, on x64 eax is a 32-bit sub-register consisting of the lower half of the 64-bit rax register. Both eax and rax are interesting, as they are used by x86 and x64, respectively, for pointers or integers returned by a function. Naturally, for a function running on x86 to return a 64-bit value it needs to use a pair of registers. Pseudo Variables Probably the most common pseudo variable is $err, which displays the last error value set with the function SetLastError. The value that is displayed represents what would be returned by the GetLastError function. Send your questions and comments to mmwincpp@microsoft.com. December 2008 109

Table of Contents Feed for the Digital Edition of MSDN Magazine - December 2008

MSDN Magazine - December 2008 Contents Toolbox CLR Inside Out Advanced Basics Cutting Edge Patterns In Practice Team System Real-World WF Visual Studio OBA Tools SOA Data Access Geneva Framework Test Run Foundations Windows With C++ Going Places End Bracket

MSDN Magazine - December 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.