VMWare 6 and above has this neat debugging functionality where you can attach gdb running on a host, to a guest running inside VMWare. This allows you to debug a running kernel, or on linux running processes.
However, VMWare seems to have coded a bit of a hack to allow gdb to understand what process/threads are inside the virtual machine. Now this hack involves using something called linuxoffsets, which provides the offset for certain fields in a linux kernel struct.
So I thought I could abuse these offsets, and hopefully make them work for FreeBSD. The Linux offsets are:
|Linux Values||FreeBSD 7.1 Values||Notes|
|<version>||Version number of linux kernel, ie 0x020609 (2.6.9)|
|<next_task>||task_struct->next_task (linux < 2.4.15)||struct proc->p_list->le_next||Pointer to next task struct|
|<tasks>||task_struct->tasks (linux >= 2.4.15)||0||Pointers to prev and next task struct|
|<comm>||task_struct->comm||struct proc->p_comm||executable name|
|<pid>||task_struct->pid||struct proc->p_pid||pid of the process|
|<rsp0/esp0>||thread_struct->rsp0 (or thread_struct->esp0 32bit)||struct thread->td_sigstk->ss_sp|
|<threadsize>||0x2000 or sizeof(union thread_union->stack) (linux >= 2.6)|
|<grouplead>||task_struct->group_leader (linux >= 2.6.11)||0|
|<threadgroup>||task_struct->thread_group (linux >= 2.6.11)||0|
|<commsize>||sizeof(struct task_struct->comm)||sizeof(struct proc->p_comm)||executable name’s max len|
However, after some time I feel this isn’t going to be possible. Each value represents a offset into a Linux task_struct struct, however, nothing represents the location of the first task_struct in RAM. I suspect VMWare is figuring out the location via some other means. Since FreeBSD doesn’t have a task_struct it most likely won’t be able to find what it needs.
Regardless I’ve posted this entry in case someone wants to continue my work. However, not all is lost as my next solution involves playing with gdb-python.