I am quite new to the area of compilers. I'm using gcc and I want to get execution history of a program for a particular run i.e. only those statements which are actually executed in the last run.
Is it possible with gdb? I couldn't get relevant options in gdb which could output executed statements.
Or is there any other way of obtaining execution history?
Regards,
Nikhil.
Process Record May be what you're looking for. The link has a quick tutorial and an overview of the functionality.
From the linked wiki page:
Compile this program with -g, and load it into gdb, then do the
following:
(gdb) break main
(gdb) run
(gdb) record
This will turn on process recording, which will now record all subsequent instructions executed by the program being debugged.
Note that you can start process recording at any point (not just at
main). You may choose to start it later, or even earlier. The only
restriction is that your program has to be running (so you have to
type "run" before "record"). If you want to start recording from the
very first instruction of your program, you can do it like this:
(gdb) break _start
(gdb) run
(gdb) record
Hope this helps.
You can use set history save command to start recording history. This can be written into the ~/.gdbinit file. Look at the docs for more information.
Related
Gameconqueror can update the variables it found continuously without stopping the program it's tracing. But as I know you have to use ptrace() to gain access of the specified program and when you do that it automatically stops the debuggee. But somehow Gameconqueror manages to do it's job without interrupting the debuggee(and it updates itself like every half second).
I think if Gameconqueror can do it, also gdb should be able to do it. I tried to enter some commands after continuing the debuggee, gdb doesn't give any error but also doesn't display anything. I'm very confused.
You need to make use of asynchronous mode within gdb. This is documented here:
https://sourceware.org/gdb/onlinedocs/gdb/Background-Execution.html#Background-Execution
For example:
(gdb) continue &
Will continue your program and then immediately return to the command prompt, allowing you to issue further commands while your program is still running.
If you want to stop your program you need to use the interrupt command, as the usual Ctrl+c will not work.
Occasionally I find myself accidentally triggering a GDB command that takes a long time to complete. An example would be setting a breakpoint using tab-completion on the symbol name. Hitting tab an extra time or two can sometimes trigger GDB listing ALL loaded symbols. Then I have to wait for a few minutes while that completes. Is there a way to interrupt the GDB command other than just killing the whole debugging session?
Hitting CTRL-C in gdb should interrupt the last (time consuming) command issued. See this article on Debugging with gdb for more info.
I have been debugging in GDB (C code). The issue is if I run my application and if it crashes, the control comes back to main()(app restarts). Hence will have no idea where it crashed. So I spend a lot of time stepping through each function.
I would like to know if there is anyway a log can be enabled which will generate the last line of execution before crash. This is just my assumption, if there is any other simpler way of doing this please let me know, this would save a great deal of time for me!
Also if the gdb generates a log where would the path be?
Thanks in advance.
This question is a little unclear to me, but I'll take a stab:
If you have GDB attached to the crashing process when it crashes, a crash should stop the program and put you back at the (gdb) prompt. If you then type bt, you should see the stack.
If you do NOT have GDB attached, then this answer to a related question might help. (In short, maybe you want the system to create a core dump when the program crashes. A core dump is just a file that contains a lot of information about the crashed process. You can use GDB with the core dump to see the stack.)
If you don't know, post what you see on the screen when this happens, and we'll guess.
In any case, the program definitely should not start over at main(). It seems worthwhile to track down why this happens and precisely what's going on. Does control really jump to main in the same process, as opposed to another process somehow being automatically started?
Run your program in gdb mode.
$ gdb ./myProgram
Set break point to expected location.
$ break functionName
Or set break point to particular line number.
$ break 15
Start the execution
$ r
Step into or step out the execution by 's' or 'n'
$ s
once the program crash, do 'bt' for backtrace.
$ bt
you can go up and down in your trace by 'up' & 'down' command
$ up
Can also take alternate way. Debug program with “core” as the core dump file.
$ gdb executableFilename core
$ bt
To debug multithreaded programs to in case of conditions such as deadlock or livelock, what are the useful utilities? I was wondering if gcore gives the stack dump of all running threds in the process or just the main thread. Also, does gcore suspend/kill the running process? Any information on debugging multithreaded programs will be very useful.
gdb supports switching between threads to investigate the state of everything going on. Here is some more information.
gdb has some nice features for working with threads. One of my favorites is thread apply. This allows you to run the same command for multiple threads.
For example, if you wanted to get a backtrace of all threads, you can use this:
thread apply all where
To break this down, the command starts with thread apply.
Next is the list of threads. Here I used the keyword all to apply this to every thread in the process. You can also use a space separated list of the gdb thread ids (thread apply 1 2 3 command).
And finally comes the command to perform. I used where which shows you the call stack but you can use any command you want.
As Carl stated, gdb supports threads. Using a UI (such as one provided by Eclipse) for GDB makes this easier, but you can get thread information when running via the command line by typing "info threads". This will list the threads and allow you to switch by typing "thread 3" etc. Once you switch to a thread, you can do backtraces in order to see the current threads stack and other commands that you're used to using with a single threaded process.
Maybe a simple question.
When I attach to a process, I run "continue" to make it continue to run.
Then I want to some other job like "add-symbol-file" with need not interactive with target process, but after the "continue" command, the gdb console will block, so I can not do any action before I break the process.
Is there any way that I can do such thing without suspend the process?
Make sure the console which gdb is running in has keyboard focus, then press CTRL-C. This will usually result in a SIGINT signal to be sent to gdb.
With me, GDB then pauses execution of the program and accepts user commands again.
Should the CTRL-C not work (perhaps different config) try to send the signal manually:
Find out the pid of gdb such as with command top and then send a SIGINT to gdb:
kill -2 pidhere
Until recently you couldn't do what you want, but the newly released
version 7.0 of gdb has what is called a "non-stop" mode, in which the
gdb prompt / console can be used while the program is running.
See http://sourceware.org/gdb/current/onlinedocs/gdb_6.html#SEC47
You may want to study the remote gdb mechanisms a bit for something like that.
For understanding the debugging process more read this short article.