VMWare on bramp.net https://blog.bramp.net/ Recent content in VMWare on bramp.net Hugo -- gohugo.io en-GB Fri, 19 Mar 2010 00:00:00 +0000 VMWare breaks shift key https://blog.bramp.net/post/2010/03/19/vmware-breaks-shift-key/ Fri, 19 Mar 2010 00:00:00 +0000 https://blog.bramp.net/post/2010/03/19/vmware-breaks-shift-key/

I came into my office today to find that my keyboard would no longer type capital letters. The shift, caps lock, and even num lock keys seemed to be broken. After a quick WTF it was pointed out to me that VMWare occasionally does this to Linux machines. Thanks to Matt who showed me a quick solution. In a terminal just type:

setxkbmap

And everything should be back to normal. After using VMWare on Linux for a couple of years I’ve never encountered this problem!

 linuxoffsets for FreeBSD https://blog.bramp.net/post/2009/01/11/linuxoffsets-for-freebsd/ Sun, 11 Jan 2009 00:00:00 +0000 https://blog.bramp.net/post/2009/01/11/linuxoffsets-for-freebsd/

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)
<mm> task_struct->mm
<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
<thread> task_struct->thread
<pgd> mm_struct->pgd
<rsp0/esp0> thread_struct->rsp0 (or thread_struct->esp0 32bit) struct thread->td_sigstk->ss_sp
<fs> thread_struct->fs
<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.