GDB on Windows machine - debugging

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.

Related

Debugging embedded application in vim

I'm trying to debug a remote embedded system.
On the target machine I run:
gdbserver localhost:port myapp
And on the host machine I run:
gdb-multiarch myapp
(gdb) target remote ip-address:port
It works and I can debug normally.
I'd like to debug this embedded program in vim as I do using Termdebug to debug normal program.
Is there a way to run gdb-multiarch when calling Termdebug? Or is there a better alternative?
First of all, load the term debugger plugin
:packadd termdebug
Then you can use the debugger the way you know how
:Termdebug
It's in the docs 🙂

How To Debug With GDB

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.

Gdb not catching kernel panic

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.

Different Ways to Run GDB on my embedded platform

I want to run GDB on my ARM embedded board...
I have referred online that we can set up GDB server and can do remote debugging but still i am missing proper steps to set up whole environment for GDB Debugging..
Can anyone please provide me a proper guidance from cross compiling GDB to running my gdb for debugging on embedded board ??
I appreciate any inputs
I assume you have a toolchain that lets you build applications for your embedded linux platform. This should include gdb (named something like arm-linux-gdb).
Next check if linux for your board already includes gdb/gdbserver. If it does, you don't have to build anything. If it does not, configure gdb like this:
./path/to/gdb/source/configure --host=arm-linux --target=arm-linux --prefix=/path/to/installation/directory
Then make and make install.
Note that --host and --target will probably match your toolchains prefix.
As part of this installation you will get gdbserver. Install it on your board.
Then use it, as explained here. It depends on your connection type (TCP, serial), but you need to run program under gdbserver on board (gdbserver binary), then run you toolchain's gdb on PC and connect to board using "target remote" command.
Have you already looked at Buildroot? It will take care of cross-compiler and root file system. You can choose to compile host and target gdb/gdbserver, so that you'll have everything from one hand. See BR's documentation.
Remote debugging of embedded systems:
GDB, as a server, must be compiled into the debugging target build in order to support connected GDB clients. When running on the client side, there must exist a copy of the target source as well as an unstripped (of symbols) version of the executable.
GCC compilation should be done with the -g flag.
On the target/server side, run with
gdbserver <port> --attach <pid> or gdbserver host:<port> <program>
On the client side, run gdb and then
(gdb) target remote IP:PORT
What gdb client to run? Must be built with the right target processor in mind, for example
.../toolchain/bin/powerpc-linux-gdb core/mydaemon/src/mydaemon -x gdb-command-script
-x is a filename option
Hope this helps!
Remote debugging of embedded systems: GDB, as a server, must be compiled into the debugging target build in order to support connected GDB clients. When running on the client side, there must exist a copy of the target source as well as an unstripped (of symbols) version of the executable.
GCC compilation should be done with the -g flag.
On the target/server side, run with
gdbserver --attach or gdbserver host:
On the client side, run gdb and then
(gdb) target remote IP:PORT
What gdb client to run? Must be built with the right target processor in mind, for example
.../toolchain/bin/powerpc-linux-gdb core/mydaemon/src/mydaemon -x gdb-command-script
-x is a filename option
Hope this helps!

Attaching to a remote process for debugging

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...)

Resources