GDB commands for WinDbg users

Most of the debugging I’ve done has been on Windows using WinDbg (or kd, cdb, ntsd). Now I’m doing some GDB debugging on Linux, so I’m trying overcome my muscle memory of typing WinDbg commands. I’m sharing my table for translating WinDbg commands to GDB.

Action WinDbg GDB
Set breakpoint bp [addr]
bp [name]
b[reak] *[addr]
b[reak] [name]
List breakpoints bl i[nfo] b[reakpoints]
Enable breakpoint be [n] en[able] [n]
Disable breakpoint bd [n] dis[able] [n]
Clear one breakpoint bc [n] d[elete] [n]
Clear all breakpoints bc * d[elete]
Disassemble u
u [addr]
disas[semble] /r
disas[semble] /r [addr]
Run g
g [addr]
r[un]
sta[rt]
Continue g
gc
c[ontinue]
Restart .restart r[un]
Trace (into calls) t s[tep]
Step (over calls) p n[ext]
Trace (into calls)
by machine instruction
t s[tep]i
Step (over calls)
by machine instruction
p n[ext]i
Toggle source mode
for stepping
l+t
l-t
n/a - See above.
(use si and ni
)
List modules lm i[nfo] sh[aredlibrary]
View registers r
r [name]
i[nfo] r
i[nfo] r [name]
View call stack k[b|v|p] i s[tack]
bt f[ull]
View threads ~ i[nfo] th[reads]
Switch thread ~[n]s thr[ead] [n]
View all thread stacks ~*k thread apply all bt
Switch frame .frame [n] f[rame] [n]
View memory (8 bytes) dq [addr] L[n] x/[n]xg [addr]
View memory (4 bytes) dd [addr] L[n] x/[n]xw [addr]
View memory (2 bytes) dw [addr] L[n] x/[n]xh [addr]
View memory (1 byte) db [addr] L[n] x/[n]xb [addr]
View memory (ascii) da [addr] L[n] p[rint] (char*)[addr]
x/s [addr]
x/20c [addr]
View memory (stacked) dds [addr] L[n] x/xw [addr]
repeat Enter key
View local variables dv /v
x
i[nfo] lo[cals]
print [var_name]
x &[var_name]
View global variables x [mod]!* i[nfo] va[riables]
info address [g_name]
print [g_name]
x &[g_name]
View frame args x
kP L1
i[nfo] ar[gs]
View type dt [type] explore [type]
Break on syscall catch syscall [i]
catch syscall [name]
Set register r [name]=[value] set $[name]=[value]
Evaluate ? [expr]
e.g. ? rax+5
p [expr]
e.g. p $r11+5
Quit q q

Notes:

  • GDB: Prefix breakpoint memory addresses with *
  • GDB: “set disassembly-flavor intel” for disassembly more like WinDbg
  • GDB: “start” runs to the entry point (if named “main”)
  • In the View memory commands, “n” represents the number of values
  • For viewing local variables, be sure to compile with symbolic information:
      • gcc -g
      • cl /Zi

     

Advertisements

The Desktop Heap Guy

When I worked at Microsoft as an Escalation Engineer, I spent my days analyzing various failures in Windows. My team was called CPR, Critical Problem Resolution, and we were there to debug issues discovered in Windows by Microsoft’s customers. These problems came to my team because they were either “critical situations” for a business customer, or because the issue was particularly technically challenging.

In this role I worked on all kinds of weird failures, but one type of issue became a regular thing for me: desktop heap failures. I didn’t set out to be an expert on desktop heap, but when a more senior engineer on my team decided that someone else needed to understand desktop heap, I was asked to become the subject matter expert.

I started investigating every customer case that looked like the root cause might be a desktop heap failure. The symptoms were usually one of two things:

1. Processes would fail to start altogether.
2. An application would run but certain windows would fail to display.

This was perplexing for users and developers alike. The underlying cause wasn’t obvious, and the same software that had previously worked without issue would suddenly start failing. There was already some limited documentation on this problem, including a KB article, but I needed more information if I was going to really understand the problem and help customers.

I quickly learned that only a handful of people at Microsoft actually knew anything about desktop heap! So I studied the Windows source code, reached out to some other engineers on the Windows team, and began to pull together an understanding of the problem. I continued to get involved with every reported desktop heap failure, and eventually I became the unofficial Desktop Heap Guy. Within Microsoft support, people had learned that there was this person who actually wanted to help with desktop heap issues! This of course led to me getting even more cases to investigate.

Eventually I decided that we really needed some documentation on desktop heap. This led to me writing series of blog posts, and recording a Channel 9 video. Even better, changes were made to the memory manager in Windows Vista and Windows Server 2008 that helped avoid the problem altogether, and the problem mostly became of thing of the past. Even so, for years after I left the Escalation Engineer role at Microsoft I would still get questions about desktop heap. Once the Desktop Heap Guy, always the Desktop Heap Guy, I guess!

explaining_desktop_heap
That’s me, explaining desktop heap in 2007

MonoGame and shared projects

When targeting multiple platforms with Xamarin, a common approach is to use a Visual Studio shared project for the code or assets that are common. In the case of a MonoGame project, this means moving the .mgcb file to a shared project. However, a shared project doesn’t support a Build Action of “MonoGameContentReference”. A simple fix to this is to open the .projitems file from the shared project in a text editor, and change the ItemGroup entry for the .mgcb file from “None” to “MonoGameContentReference”. A disadvantage to this approach is that the Visual Studio IDE will no longer show the .mgcb file, but the build should work.

Proliferation of Dependencies

Ten years ago or so, I wrote lots of relatively small Windows applications. It was important to me to minimize dependencies on external libraries besides those available in Windows. I wanted to ship a single exe that anyone could drop on Windows 2000 or later and run it without installing anything else. To that end I wrote my code in C against the Win32 API directly. No MFC, no .NET, or anything else. If I could restrict my calls to functions in kernel32, user32, gdi32, and advapi32, all the better.

This weekend I’ve been working on a web application. While reflecting on my Win32 days, it struck me just how many dependencies I’ve taken to deliver this web application. Of course there’s the baseline trio of HTML, CSS, and JavaScript, but then I’m also leveraging Node.js, Express, Jade, Passport, Socket.io, MongoDB, jQuery, and Knockout, plus a bunch of other small npm packages. Wow, what a change from my old “minimize dependencies” philosophy!

Digest authentication with Express 4

While adding digest authentication to a Node.js / Express 4 site, I ran into an issue. I was using Passport middleware for authentication, along with the passport-http strategy. Authentication worked fine with an Express router for my root path, but when I added authentication to a sub path (e.g. /api/cats) every request failed with an HTTP 400.

After some debugging, I found that digest.js from passport-http checks that the request URL matches the URI that was supplied with the authentication credentials. This is a problem because a mounted route handler sets req.url to a path relative to the mounted path, so in the example above req.url is ‘/’ while creds.url is ‘/api/cats/’, and the string comparison fails.

It turns out I’m not the first to encounter this, and there’s already a pull request for a fix, but it hasn’t been merged yet. In the meantime, I didn’t want to modify the passport-http code, so I made a change in my code to work around the issue. I added a custom middleware function that was called immediately before calling passport.authenticate that updates req.url using the same approach as in the pull request fix. Of course a side effect of this is that now req.url is no longer relative to the mounted path, but that isn’t an issue for my code.

// Middleware to ensure req.url works with digest auth
function (req, res, next) {
    req.url = (req.baseUrl ? req.baseUrl : "") + req.url;
    next();
}

Arduino Simon

Last year I decided to build a simple Simon style game using an Arduino. The game has four LEDs, each a different color, and a corresponding button for each LED. The game lights up a pattern of LEDs, one after another, and the player repeats the pattern to progress to the next level. Each level builds upon the previous level by adding one more element to the sequence. There is also a simple buzzer that provides audio feedback. Each LED is assigned a pitch that is played when it lights up, and there’s a victory “song” that is all of two notes!

Hardware

The LEDs were connected to digital pins on the Arduino via 220 ohm resistors. The buttons, or momentary switches, were connected to digital pins using 10k pull down resistors. The buzzer was connected directly to a digital pin. Turns out the buzzer was really loud, so I made a covering out of clay to reduce the volume. I originally used an Arduino Uno, but later decided I wanted something more compact, so I changed to the Nano. I also started with tiny DIP push buttons, but they were difficult to use, so I swapped them out for bigger push buttons.
simon-arduino-circuit-diagram

Parts List

The Code

The tone function was used to play notes on the buzzer. To create a random sequence for the player, I used the random function, and set the seed with an analogRead from pin zero, which was floating. The rest was just digitalWrite (to set the LED states), digitalRead (to check the button presses), delays, and keeping track of game state in memory.

Photos

v1 – With tiny buttons and Arduino Uno
simon-arduino-v1

v2 – With bigger buttons and Arduino Nano
simon-arduino-v2