I have been trying to attach recent builds of gdb (archer's python branch: http://sourceware.org/gdb/wiki/PythonGdb) to the VMware debug stub. I've found 2 apparent gdb bugs and 1 that appears to be an issue with the VMware stub.

The gdb bugs can be found here, for completeness:

http://sourceware.org/ml/archer/2009-q3/msg00188.html

http://sourceware.org/ml/archer/2009-q3/msg00198.html

With those bugs fixed, I can perform an "info threads" after providing the linuxoffsets and get a list of all the live threads. However, attempting to switch to the thread via "thread GDBTHREADNUMBER" fails because when gdb asks about the thread, VMware's response makes it think the thread is dead. This causes it to not switch to the thread. For example, if the GDB thread number is 179 and the underlying thread id is 3008, "thread 179" results in a payload of "Tbc0". VMware responds with "E00" which makes gdb think the thread is dead, as per the spec on the command.

If I modify gdb so that remote_thread_alive in remote.c always returns true (and does not issue the command), things work as they used to work in my older setup.

I am using VMware workstation 6.5.3 with up-to-date Ubuntu 9.04 i386 guests on an Ubuntu 9.04amd64 host. In my old setup I used the gdb debugger that shipped with Ubuntu 9.04 with Workstation 6.5.2 (or maybe 6.5.1?). The system gdb no longer works, so I presume there was an update to gdb on 9.04 that broke things, but I have not investigated heavily since I'd rather use a modern gdb works (and can be scripted with python!) than figure out what ancient version works.

My idea of what works is: Attach with archer-gdb without having specified an executable. Tell it about the linux offsets, do "info threads", find the first thread in the process I care about, switch to that thread. Detach and quit. Attach with archer-gdb having specified an executable. Things are now in a state where I have a valid backtrace and gdb's understanding of the executable's layout in memory appears correct.