I'd like to have gdb immediately run the executable, as if I'd typed "run"
(motivation: I dislike typing "run").
One way is to pipe the command to gdb like this:
$ echo run | gdb myApp
But the problem with this approach is that you lose interactivity with gdb,
eg. if a breakpoint triggers or myApp crashes, gdb quits.
This method is discussed here.
Looking at the options in --help, I don't see a way to do this, but perhaps I'm missing something.
gdb -ex run ./a.out
If you need to pass arguments to a.out:
gdb -ex run --args ./a.out arg1 arg2 ...
EDIT:
Orion says this doesn't work on Mac OSX.
The -ex flag has been available since GDB-6.4 (released in 2005), but OSX uses Apple's fork of GDB, and the latest XCode for Leopard contains GDB 6.3.50-20050815 (Apple version gdb-967), so you are out of luck.
Building current GDB-7.0.1 release is one possible solution. Just be sure to read this.
I would use a gdb-script:
gdb -x your-script
where your-script contains something like:
file a.out
b main
r
afterwards you have the normal interactive gdb prompt
EDIT:
here is an optimization for the truly lazy:
save the script as .gdbinit in the working directory.
Afterwards you simply run gdb as
gdb
... and gdb automatically loads and executes the content of .gdbinit.
(echo r ; cat) | gdb a.out
The cat allows you keep typing after gdb breaks.
start command
This command is another good option:
gdb -ex start --args ./a.out arg1 arg2
It is like run, but also sets a temporary breakpoint at main and stops there.
This temporary breakpoint is deactivated once it is hit.
starti
There is also a related starti which starts the program and stops at the very first instruction instead, see also: Stopping at the first machine code instruction in GDB
Great when you are doing some low level stuff.
gdb -x <(echo run) --args $program $args
Related
I'm receiving this gdb error on any code I try to debug any program with gdb. Here's the simplest process that reproduces the error
Create a main.cpp file with this content:
int main(){
return 0;
}
Run g++ -g main.cpp
Run gdb a.out
Inside gdb set a break point at line 2 with break 2
In gdb run the program with run
Output:
Starting program: /tmp/test/a.out
During startup program exited normally.
This is all done with gdb on the command line. I've tried using g++ and gcc with the same result. I'm not really sure where to go from here.
gdb version = 9.2
g++ version = 9.3.0
EDIT: I figured out what is causing the issue, but not how to fix it. The issue seems to be something related to my SHELL variable. I'm currently using xonsh as my shell but when I set my SHELL environment variable back to /bin/bash everything works as expected. Is there anything I can do to fix this while using xonsh? Should I report this to xonsh, gdb, both or neither?
I'm currently using xonsh as my shell but when I set my SHELL environment variable back to /bin/bash everything works as expected. Is there anything I can do to fix this while using xonsh? Should I report this to xonsh, gdb, both or neither?
This might be your xonsh startup problem, or it might be xonsh problem, or it could be that xonsh doesn't do what GDB expects it to do.
Normally, GDB forks / execs $SHELL -c "/path/to/your/exe $args" and expects the $SHELL to exec your program (this is done so shell redirection still works under GDB).
Only after that exec will GDB start setting breakpoints, etc.
If you have some xonsh init-file, which e.g. causes xonsh to exec something else, things could go bad. So I suggest trying to remove any such ~/.xonshrc or whatever it's called file, and seeing whether that fixes the problem.
If it doesn't, it could be that xonsh e.g. forks and execs your binary in a child (grandchild of GDB) instead of doing it directly, or it could be that xonsh doesn't understand the -c ... syntax.
If you don't care about redirection, you could also ask GDB to not use $SHELL at all: set startup-with-shell off. Documentation.
How can I run something like gdb -e path/to/exe -ex 'run --argnamae argvalue'?
Let's assume a recent version of gfb, within the past year or two.
Gdb runs and prints responses but not interactively.
I think you want gdb --args path/to/exe command line arguments
which will start gdb debugging path/to/exe pass three command line arguments to your exe command, line, and arguments, you can then interact with gdb before issuing the run command.
As for the ImportError: No module named 'libstdcxx' I believe this is already answered here which points to a bug report here.
It appears some versions of GCC have a broken pretty printers python script, you might need to adjust the python sys.path with (gdb) python sys.path.append("/usr/share/gcc-4.8/python"), adjust the path to match whatever GCC version is actually present on your system. You could probably add a command like this to your .gdbinit file to save typing it every time.
How can I run something like ...
You can do this:
gdb path/to/exe -ex 'set args arg1 arg2 arg3'
Or use a shorthand notation for the above:
gdb --args path/to/exe arg1 arg2 arg3
If you want to pass arguments from file,
try this
(gdb) run < the_file_contains_data
Does anybody know how so use gdb in emacs?
I am using this command to create my program
/home/cdim/Local/gcc-4.9.2/bin/gfortran -ffree-form -g ./utests/test_gdb.f -o test_gdb
I am going to Emacs Tools then Debugger (GDB). I then click on the run button and nothing happens.
What does test_gdb do if you run it outside of gdb? If it sends no output to the screen then this (i.e., no output) is exactly what you will see when you run it inside of gdb - if you have set no breakpoints. Did you set a breakpoint? And how much nothing happens when you click run? Even if test_gdb produces no output, if all is well you should still see gdb display a notification like
[Inferior 1 (process 12345) exited normally]
Consider test.f:
Program p
Integer :: i = 1
Print *, i
End
I would compile this with gfortran -ffree-form -g -ggdb test.f -o test_gdb.
(From https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Debugging-Options.html#Debugging-Options:
-ggdb
Produce debugging information for use by GDB. This means to use the most expressive format available (DWARF 2, stabs, or the native format if neither of those are supported), including GDB extensions if at all possible.
)
Then, as you said, go to Tools -> Debugger (GDB) (or issue M-x gdb) in emacs and make sure the gdb invocation is using the full path to the executable, e.g. Run gdb (like this): gdb -i=mi /foo/bar/test_gdb. Hit return in that minibuffer.
Now, set a breakpoint in the new *gud-test_gdb* buffer:
(gdb) break p
Breakpoint 1 at 0x4007e1: file test.f, line 3.
Then go to menu entry Gud -> Run.
Esc+x then entern gdb ... and input your application file. it will start gdb in emacs
I solved problem by moving to Trisquel 7.0. Might have been a setup problem.
Whe loading a program with gdb, how do you have gdb automatically start the program and run it without waiting?
Use the -ex command line option and provide the run command.
gdb -ex=r --args executable --with-options-for-the-executable
I usually run a program as :
./a.out arg1 arg2 <file
I would like to debug it using gdb.
I am aware of the set args functionality, but that only works from the gdb prompt.
You can do this:
gdb --args path/to/executable -every -arg you can=think < of
The magic bit being --args.
Just type run in the gdb command console to start debugging.
Pass the arguments to the run command from within gdb.
$ gdb ./a.out
(gdb) r < t
Starting program: /dir/a.out < t
If you want to have bare run command in gdb to execute your program with redirections and arguments, you can use set args:
% gdb ./a.out
(gdb) set args arg1 arg2 <file
(gdb) run
I was unable to achieve the same behaviour with --args parameter, gdb fiercely escapes the redirections, i.e.
% gdb --args echo 1 2 "<file"
(gdb) show args
Argument list to give program being debugged when it is started is "1 2 \<file".
(gdb) run
...
1 2 <file
...
This one actually redirects the input of gdb itself, not what we really want here
% gdb --args echo 1 2 <file
zsh: no such file or directory: file
Start GDB on your project.
Go to project directory, where you've already compiled the project executable. Issue the command gdb and the name of the executable as below:
gdb projectExecutablename
This starts up gdb, prints the following:
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
.................................................
Type "apropos word" to search for commands related to "word"...
Reading symbols from projectExecutablename...done.
(gdb)
Before you start your program running, you want to set up your breakpoints. The break command allows you to do so. To set a breakpoint at the beginning of the function named main:
(gdb) b main
Once you've have the (gdb) prompt, the run command starts the executable running. If the program you are debugging requires any command-line arguments, you specify them to the run command. If you wanted to run my program on the "xfiles" file (which is in a folder "mulder" in the project directory), you'd do the following:
(gdb) r mulder/xfiles
Hope this helps.
Disclaimer: This solution is not mine, it is adapted from https://web.stanford.edu/class/cs107/guide_gdb.html
This short guide to gdb was, most probably, developed at Stanford University.
Wouldn't it be nice to just type debug in front of any command to be able to debug it with gdb on shell level?
Below it this function. It even works with following:
"$program" "$#" < <(in) 1> >(out) 2> >(two) 3> >(three)
This is a call where you cannot control anything, everything is variable, can contain spaces, linefeeds and shell metacharacters. In this example, in, out, two, and three are arbitrary other commands which consume or produce data which must not be harmed.
Following bash function invokes gdb nearly cleanly in such an environment [Gist]:
debug()
{
1000<&0 1001>&1 1002>&2 \
0</dev/tty 1>/dev/tty 2>&0 \
/usr/bin/gdb -q -nx -nw \
-ex 'set exec-wrapper /bin/bash -c "exec 0<&1000 1>&1001 2>&1002 \"\$#\"" exec' \
-ex r \
--args "$#";
}
Example on how to apply this: Just type debug in front:
Before:
p=($'\n' $'I\'am\'evil' " yay ")
"b u g" "${p[#]}" < <(in) 1> >(out) 2> >(two) 3> >(three)
After:
p=($'\n' $'I\'am\'evil' " yay ")
debug "b u g" "${p[#]}" < <(in) 1> >(out) 2> >(two) 3> >(three)
That's it. Now it's an absolute no-brainer to debug with gdb. Except for a few details or more:
gdb does not quit automatically and hence keeps the IO redirection open until you exit gdb. But I call this a feature.
You cannot easily pass argv0 to the program like with exec -a arg0 command args. Following should do this trick: After exec-wrapper change "exec to "exec -a \"\${DEBUG_ARG0:-\$1}\".
There are FDs above 1000 open, which are normally closed. If this is a problem, change 0<&1000 1>&1001 2>&1002 to read 0<&1000 1>&1001 2>&1002 1000<&- 1001>&- 1002>&-
You cannot run two debuggers in parallel. There also might be issues, if some other command consumes /dev/tty (or STDIN). To fix that, replace /dev/tty with "${DEBUGTTY:-/dev/tty}". In some other TTY type tty; sleep inf and then use the printed TTY (i. E. /dev/pts/60) for debugging, as in DEBUGTTY=/dev/pts/60 debug command arg... That's the Power of Shell, get used to it!
Function explained:
1000<&0 1001>&1 1002>&2 moves away the first 3 FDs
This assumes, that FDs 1000, 1001 and 1002 are free
0</dev/tty 1>/dev/tty 2>&0 restores the first 3 FDs to point to your current TTY. So you can control gdb.
/usr/bin/gdb -q -nx -nw runs gdb invokes gdb on shell
-ex 'set exec-wrapper /bin/bash -c "exec 0<&1000 1>&1001 2>&1002 \"\$#\"" creates a startup wrapper, which restores the first 3 FDs which were saved to 1000 and above
-ex r starts the program using the exec-wrapper
--args "$#" passes the arguments as given
Wasn't that easy?