OSDev.org

I'm not sure if this is the right place, but:

Does anyone know a pointer to some documentation of virtualbox debugger syntax?
The virtualbox manual gives some commands and there is the help, but neither of them
describes the command parameters.

Even google doesn't seem to be my friend on this.
(Tried to find about OS2 debugger and CodeView debugging too.)

IMHO, using Bochs/QEmu/VMWare with GDB-stub or internal Bochs debugger is a much better idea. GDB is a truly universal tool.

About VBox, hm:
https://www.google.com/search?q=virtual ... l+debugger -> http://stackoverflow.com/questions/2045 ... irtual-box -> http://www.virtualbox.org/manual/ch12.html#ts_debugger ->

A brief summary of frequently used commands follows:
stop -- stops the VM execution and enables single stepping
g -- continue VM execution
t -- single step an instruction
rg/rh/r -- print the guest/hypervisor/current registers
kg/kh/k -- print the guest/hypervisor/current call stack
da/db/dw/dd/dq -- print memory contents as ASCII/bytes/words/dwords/qwords
u -- unassemble memory
dg -- print the guest's GDT
di -- print the guest's IDT
dl -- print the guest's LDT
dt -- print the guest's TSS
dp* -- print the guest's page table structures
bp/br -- set a normal/recompiler breakpoint
bl -- list breakpoints
bc -- clear a breakpoint
writecore -- writes a VM core file to disk, refer Section 12.1.4, “VM core format”
See the built-in help for other available commands.
[...]

but neither of them describes the command parameters.

A lot of commands has 0 parameters, most of the other commands has 1 parameter - something like address.

I've seen that manual page and tried help, but it doesn't tell what's wrong in these:
or if there is 'dot'.

=> what kind of forms of parameters are allowed.

For me qemu/ddd seems to be unstable. The debugger seems to randomly loose connection to
keyboard (but not the mouse - I can click to the 'gdb terminal window' or command button, but can't write
anything on the gdb terminal) and sometimes the whole desktop (host) jams (Ubuntu 14.04 LTS 32-bit).
qemu/nemiver seems to work a bit better, but sometimes it seems to suddenly crash too. I just would like to check if virtualbox/vbox debugger was more stable.

I found this: http://www.redbooks.ibm.com/redbooks/pdfs/sg244641.pdf
but it it seems that the commands are slightly different.

turboscrew wrote:I've seen that manual page and tried help, but it doesn't tell what's wrong in these:

Code: Select all

VBoxDbg> bp main
Error: Unknown error -11003!
VBoxDbg> bp _main
Error: Unknown error -11003!

To use symbols (i.e. names of functions/variables) you need the way to load them. I'm not sure whether VirtualBox provides such option.
Once again: if you didn't load symbolic (debugging) information, you cannot use names, only numeric addresses.

turboscrew wrote: For me qemu/ddd seems to be unstable.

DDD (btw, it's just a front-end for GDB that tries to interract with it using pipe, i.e. emulating user input and parsing GDB's output) is a pile of old crap. It's not polite to say such things but it's a sad truth. Using GDB directly (maybe in TUI mode) in terminal is the best option. I've seen also pictures about successfull integration of Eclipse-CDT with GDB and VMWare (you can replace VMWare with QEmu, of course), this is an option for you if GUI is too highly desired.

turboscrew wrote:I just would like to check if virtualbox/vbox debugger was more stable.

IMHO, VirtualBox is full of quick-and-dirty things.

I have kinda got used to GUIded debuggers...
CDT is a good point. (Because I guess the problems were not in GDB, but in the front ends.)

...or then not...
That happens when in the debugger I send 'continue' to the remote target.
It works with DDD, Nemiver and 'raw' GDB.

----------------
In first terminal: in second terminal: (Sorry, should have used -q.)

Sorry, but I don't get your current question.

turboscrew wrote:...or then not...

Code: Select all

~/OXkernel/ox$ qemu-system-i386 -s -S -fda ~/OXkernel/ox/vmox.imgqemu: fatal: Trying to execute code outside RAM or ROM at 0x000a0000

That happens when in the debugger I send 'continue' to the remote target.
It works with DDD, Nemiver and 'raw' GDB.

Did you want to say that without debugger you don't receive QEmu's warning about attempt to execute code from video RAM area?

Btw, it looks like everything is ok with gdb (note: gcc's key `-g' includes some debugging information in ELF files but you can possibly get more details with -ggdb, see 'man gcc' for further information), did you try to inspect current state after interruption with such commands as 'info registers', 'x/i $eip', 'bt', 'info locals'?

That happens if I try to use GDB via eclipse.
With GDB without other frontends (or without any front end) that doesn't happen.
(The other frontends: ddd and nemiver seem to have different problems)
The "or rhen not" was meant for continuation to
"CDT is a good point. (Because I guess the problems were not in GDB, but in the front ends.)"