How do I sent a breakpoint at a particular address/line of code when debugging a guest OS in VirtualBox? I found the debugger instructions (https://www.virtualbox.org/manual/ch12.html#ts_debugger), but I don't see how to get the guest OS to stop executing at the point where I want to start examining the execution closely.
For more context: I am trying to debug a "toy" OS I'm writing. I test the OS by running it in VirtualBox. By following the instructions above, I can use the debug interface to examine the state of the guest OS/cpu after it halts (or enters an infinite loop); but, I don't see how to get the guest OS to stop/pause at a certain instruction. There is a "stop" command; but, by the time I can open the debug command line and enter the command, the OS has already run to completion. (My toy OS is not yet interactive.)
Related
Let us say I am on a Windows machine and I goto its command line terminal and type 'gdb' there. I get gdb prompt (gdb) as shown in the following image. It means gdb.exe is installed on the machine.
My understanding is that the GDB is client-server application. I want to know is this gdb.exe the gdbserver or gdbclient? If its the former then where would be the later and if its the later then where would be the former in this case?
GDB can be a client server application, but it doesn't have to be.
What you started is gdb itself, so, the client side. The server is actually called, gdbserver.
Usually, you'd make use of gdbserver when you want to debug something running on a different machine over a network (though there's nothing to stop you running gdbserver on the same machine as gdb itself).
You can also use gdb to directly start an application to debug, so at the (gdb) prompt you might do:
(gdb) file /path/to/some/executable
(gdb) break main
(gdb) run
For further reading the manual has lots of details, there's a simple example session and more details on remote debug.
I'm learning how to write a basic OS kernel with intermezzos.github.io
I'm running in Windows Subsystem for Linux on Windows 10 v1607.
I'm at the point where I want to run my .iso with qemu-systems-x86_64 -cdrom os.iso.
Previously I was able to run the command and QEMU would run a window, which was running into another problem, posted here: QEMU, No bootable device, Windows Subsystem for Linux
Now when running the command, I receive the following error: Could not initialize SDL(No available video device) - exiting
When I ran into this problem before I installed Xming, ran it, and then QEMU successfully ran. But now, when I try to run Xming it no longer solves the problem.
I even tried installing xorg and running startx on WSL but that starts another issue: xf86OpenConsole: Cannot open /dev/tty0 (No such file or directory)
I really don't know what I'm doing and I have so many questions.
I'm under the impression that for QEMU to successfully run, it needs to be able to find a video driver. Is that the purpose of X11?
I am able to get qemu-system-x86_64 -cdrom os.iso to run the expected window after setting: export DISPLAY=:0
Partially solves my problem because I'm still running into QEMU, No bootable device, Windows Subsystem for Linux
I'm wondering if I'm setting the DISPLAY environment variable correctly.
Here's documentation on the DISPLAY variable, for anyone else that wants to learn: http://gerardnico.com/wiki/linux/display
Anyway, this portion is solved!
I have an ARM Linux kernel running as part of the android emulator where I'm doing a bit of testing. I start the emulator without the GUI stuff, and just use adb shell to access the emulator's internal memory.
I start up the emulator on an OSX machine as follows :-
$ emulator -verbose -debug init -show-kernel -kernel ./zImage -avd debug -no-boot-anim -no-skin -no-audio -no-window -qemu -gdb tcp::1234
I attach gdb to the emulator as follows :-
$ arm-eabi-gdb ./vmlinux
(gdb) target remote :1234
I know that the attaching works well, because if I attach the debugger earlier on, I can see that the boot process pauses till I press "c" in gdb. However, when a kernel panic arises in the emulator, I see a stack trace on the terminal that runs the emulator -- however, I don't see any change on the gdb side. The machine halts when the kernel panics, so I'd assume that gdb would show some indication of the same. Why doesn't this happen?
When I Ctrl-C at the emulator side to stop QEMU, I get the message emulator: Done with QEMU main loop. emulator: User-config was not changed. and gdb shows Remote connection closed.
What as I missing here?
Placing a breakpoint on panic and inspecting the backtrace is a possible solution to the problem.
The instructions found at Setting Up Kernel Debugging are what I used to get to this point. On the machine running the kext I want to debug, I do see the message "Connected to remote debugger". On the machine I am running gdb on, I do see:
(gdb) kdp-reattach localhost
Connected.
The problem is that 'showallkmods' returns an empty list and none of the other similar commands appear to be working:
(gdb) showallkmods
kmod address size id refs version name
(gdb) showalltasks
task vm_map ipc_space #acts pid process io_policy wq_state command
Invalid type combination in equality test.
(gdb) showregistry
Please load kgmacros after KDP attaching to the target.
(gdb) source /Volumes/KernelDebugKit/kgmacros
Loading Kernel GDB Macros package. Type "help kgm" for more info.
(gdb) showallkmods
kmod address size id refs version name
(gdb) showregistry
Please load kgmacros after KDP attaching to the target.
(gdb) showbootargs
Invalid cast.
I am running 10.6.8 and am using kernel_debug_kit_10.6.8_10k540.dmg
I am not sure what other details one might need to diagnose what has gone wrong, but if you want to ask questions in the comments, I can certainly attempt to provide additional details.
The error "Invalid type combination in equality test." indicates to me that gdb might be expecting a different CPU architecture than the kernel you're connecting to is running. The 10.6 kernel exists in both 32-bit and 64-bit variants, and by default it's determined by the hardware which one gets loaded. gdb normally defaults to x86_64 if your CPU supports it (true of all Intel Macs except the very early Core Duo based ones) so if you're connecting to a 32-bit kernel (the default on most Macs released before 2011) you need to pass the -arch i386 argument when starting gdb. You can check the current kernel CPU architecture by running the uname -a command.
Update: on OSX Mountain Lion, the kernel always runs in 64-bit (x86_64) mode. On OSX Lion, the kernel defaults to 64-bit mode on Macs which are capable of running Mountain Lion and in 32-bit mode otherwise.
Using Xcode 3.1 on OSX 10.5; is it possible to attach (the debugger) to a running remote process?
I know that it's possible to start and debug a remote process (as explained here), but it would be great if I could find a way to attach to an already running remote process...
edit to add: Thanks. I've submitted a bug report to Apple. Will update this question if/when I hear back from them.
There is no nice gui for it in XCode but you can do it this way:
start a second instance of the program from XCode with remote debugging,
use the GDB attach command from the console
Step by step instructions:
Follow Apple's instructions to set up remote debuging:
Find out the process-id of the running instance of your program on the remote box:
ssh "remotemachine" 'ps -x -w -w' | grep "AppName"
(you can also use ARD and ActivityMonitor)
Put a breakpoint to your app main, and start a second instance from the Debugger (on the remote box)
In the GDB console (Run/Console menu) enter:
attach process-id
Now you have you XCode attached to the running process. You can now use the graphical debugger.
(In early XCode, there was no GUI for attaching to local processes, so this trick/hack was the solution...)