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.
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 newbie to emulator. Nowadays I try to view src code of mgba(GBA Emulator).
https://github.com/mgba-emu/mgba
I built and found option -g.
-g option means Start GDB session (default port 2345) from help.
Is it able to be debugged with GDB?
How can I debug with GDB?
Please tell me how to or other methods to trace source code?
(Sorry for my poor English.)
The -g option means you can remotely debug your rom with a remote debugger of gdb like gdb, ghidra or radare2. You will need another tool as mentioned before.
Sadly you can not debug remotely a classic gameboy rom. It only works for gameboy advance roms.
If you just want to debug the rom with no remote debugging access you can still use gdb from mgba with no remote debugging using the command
mgba -d your_rom.gb
a terminal should start. Then use gdb commands such as c to continue.
If you do not like gdb, you can get a look at BGB if you prefer a more graphic debugger.
I finally managed to run GDB 8.2 on macOS. But now when I'm trying to debug something, I got the following:
(gdb) b main
Breakpoint 1 at 0x100001e94: file project/src/main.cpp, line 34.
(gdb) run
Starting program: project/cmake-build-debug/program
[New Thread 0x1203 of process 5140]
[New Thread 0xf03 of process 5140]
[5]+ Stopped sudo gdb beast
I also tried using it inside CLion. In that case, GDB freezes indefinitely with this:
For help, type "help".
Type "apropos word" to search for commands related to "word".
Function "__cxx_global_var_init" not defined.
Function "__libc_csu_init" not defined.
[New Thread 0x1003 of process 4186]
[New Thread 0xf03 of process 4186]
Warning:
Cannot insert breakpoint -1.
Cannot access memory at address 0xf7ce
Does anybody know what's going on?
[5]+ Stopped sudo gdb beast
This is a gdb bug. The typical cause of this is gdb trying to write something to stdout after it has already given the terminal to the inferior. I'm not sure whether this instance has been fixed, probably because this is most likely only showing up due to:
Warning:
Cannot insert breakpoint -1.
Cannot access memory at address 0xf7ce
... this. This is another bug in gdb, namely that it wasn't updated to account for dyld changes in High Sierra. This bug is fixed and will be in gdb 8.3 (or in any rate in the release after 8.2.1, regardless of what number it is finally given).
Building a gdb from git master will work fine.
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.)
I was trying to debug the kernel using qemu and gdb. For this I have used the concept of bridge connection between qemu and host machine. In the script I have used the tcp:17777:127.0.0.1:22 to connect the qemu machine for gdb.
But when I do ssh 17777 root#localhost (root is user of qemu), it does not respond me.
Question 1: when I will know that I am on right path means I can debug the kernel using qemu?
When we do:
gdb vmlinux
target remote :1234
Question 2: When i try to do gdb vmlinux and target remote :1234 without booting the kernel I want to debug, still I get the following output (which I get when I boot with qemu for kernel I want to boot).
(gdb) target remote :1234
Remote debugging using :1234
default_idle () at arch/x86/kernel/process.c:299
299 current_thread_info()->status |= TS_POLLING;
Help me to understand the concept in detail and share the link to debug kernel using qemu and gdb