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.
Related
Currently I have a few processes which I am trying to debug using VSCode's debugging extension which uses GDB. Each process makes calls to other processes and they all have a timeout period. The issue is that when I reach a breakpoint at one process, the other processes continue and will eventually timeout making it difficult to debug. The only workaround I have is to quickly go and pause each of my processes manually when I hit a breakpoint which often doesn't work and is inefficient. Does anyone know of say a launch.json setting I could add to vscode to make it so all the processes automatically pause and continue at the same time when a breakpoint is reached?
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.
I have a process that is already running, and I want to debug it with GDB. I've been using
gdb --pid $PID
However, when I do this, the process pauses. I'd like to attach to the process without pausing it, and look around in its memory while it's still running. Is this possible? Alternatively, is there a way to "fork" the process so that I can look at its memory, without stopping/pausing the process?
There's no way in gdb to attach without some sort of pause.
The Linux kernel provides some support for this via PTRACE_SEIZE, but gdb doesn't use this yet. There's a bug in bugzilla you can track, "Bug 15250 - use PTRACE_SEIZE and PTRACE_INTERRUPT"
Meanwhile you could try setting gdb into "observer mode". Then you could attach and use continue & to continue the process in the background. You may need to set various settings, like target-async, depending on the gdb version.
I am not totally certain if this will work. It is worth a try. Note that there is a window in which the program will be paused. This is unavoidable right now.
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.
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.