I am trying hard how in gdb we can trace functions call but not able to achieve so - is there a way in GDB that when I run the executable I can print/trace functions name currently executing?
Related
I need to set breakpoints in a cpp source file. The current setup to call the cpp target is through a shell target, with additional dependencies, which means it's not feasible to directly invoke the cpp target in Linux console.
As I searched online, there are generally two ways:
invoke gdb in shell
pause in cpp, let gdb connect to the process
I don't know how to do the first way, so I choose the second way here.
I insert sleep(30) in cpp file, then in another terminal I open gdb and connect to the running process. I confirm the gdb can stop at the sleep() function in gdb. But the problem is the gdb seems only knowing the sleep function context, without knowing the call site of the sleep function. If I force setting breakpoint in the main program, gdb shows no such file. If I continue in gdb, it will not stop at any breakpoints I set in cpp file.
You need to compile the program with debug symbols. Otherwise GDB will only know of symbols in the dynamic symbol table. Turning off optimizations also helps debugging. So add the flags -O0 -g.
If this is not possible, you'll have have to step through the disassembly (Ctrl+X, 2).
I am using Codeblocks for the first time to run a cpp program. While compling the program an error occurs, I want to know the line number from the program where the error is evoking or in other words I want to see the stack trace of the program.
How can achieve this?
You can also use gdb. To debug, compile with g++ and -g at the end of the command and then run your program with gdb (in linux, gdb ./NameOfYourProgram). Then, you type r to run it, and when an error occurs, just type where and you get the stack. You can also set breakpoints and perform steps with gdb to examine the bug further.
I'm doing an OS class that's based on xv6 and I wrote a program that needs to run on it.
I know that I can debug kernel code with make qemu-gdb but I'm not sure how to debug my own user program.
Lets say I want to debug cat, how would I go about doing that?
Thanks
P.S. isn't there an xv6 tag? should this question even go here?
From the xv6 top-level dir:
Run the emulator in debug mode (assuming no X11): make qemu-nox-gdb
In other terminal just run the debugger loading the kernel symbols with:
gdb kernel This is important, otherwise the debugger will be confused between kernel and and user program symbols, for example main()
From the gdb interface run: (gdb) target remote localhost:26000
where 26000 is the TCP port that the step #1 report at the end (this might change).
Load the user exec with (gdb)file user_program
Place a breakpoint (gdb) break main and continue with (gdb) continue
etc...
file cat, break main, continue
semi reference running and debugging xv6
While debugging a program in GDB, I get an unexpected "program exited normally". So I'm wondering if is there a way to find out from where (which line) the program exited.
Program is multi-threaded, if that matters.
You could try the GDB command break exit to set a breakpoint on the exit(2) library call. If that doesn't get you what you need, maybe break _exit. You might need to start your program with 'sta' before getting the latter breakpoint to take. In either case, you should then be able to use the where command to get a stack trace showing where you were when the program decided to exit.
Usually with the command below when the application has finished executing:
(gdb) thread apply all bt
Of course, if you want to know the exact line you must compile your application with debugging symbols, i.e. -g
Set a breakpoint on _exit and then examine the stack.
I'm trying to debug a server I wrote with gdb as it segfaults under very specific and rare conditions.
Is there any way I can make gdb run in the background (via quiet or batch mode?), follow children (as my server is a daemon and detaches from the main PID) and automatically dump the core and the backtrace (to a designated file) once the program crashes?
Assuming you have appropriate permissions, you can have gdb attach to any process. You can do it on the command line with:
gdb /path/to/binary _pid_
or from within gdb with the attach command:
attach _pid_
So, once your daemon has started, you can use either of these techniques to attach to the final PID your daemon is running as. Attaching gdb stops the process which you are tracing so you will need to issue a "continue" to restart it.
I don't know a direct way to get gdb to run arbitrary commands when the program crashes. Here is one workaround I can think of:
Create and register a signal handlers for SIGSEGV.
Tell gdb not to stop on that signal (handle SIGSEGV nostop)
Set a breakpoint at the first line of your signal handler.
Assign commands to the breakpoint from step 3
Why not just run the process interactively in a persistent screen session? Why must it be a daemon when debugging? Or just run gdb in the screen session and attach it to the running process (e.g. gdb /path/to/binary -p PID_of_binary) after it forks.
First, I'd setup your shell / environment to give you a core dump. In bash:
ulimit -c unlimited
Once you have the core dump, you can use gdb to examine the stack trace:
gdb /path/to/app /path/to/core/file
I'm not really a gdb expert but two things come to mind
Tracepoints which might give you the necessary information as your program runs or
Use gdb's remote debugging facility to debug your program while it's running as a daemon.
How to generate a stacktrace when my gcc C++ app crashes answer for this question should do what you want. (assuming you can make changes in your code)
You might want to take a look at how Samba facilitates debugging; it has a configurable "panic action" that can suspend the application, notify the developer, spawn gdb, etc., and is run as part of its signal handler. See lib/util/fault.c in the Samba source tree.
My practice: comment out daemon function call, rebuild binary, then use gdb to run.