I have a program that takes many complex command line arguments that are generated via front end bash scripts. To debug, I generally call gdb with a hand entered set of these using the 'set args' command.
What I'd like to do is run my target code on another server with gdbserver and its args there using the bash script front ends that generate the args, then connect to it with gdb and 'pick up' the args that were passed in with gdbserver on the target machine. Essentially, linking "set args" with whatever argc/argv[] are in use when main() is hit. This would allow me to re-run the target without losing the argument list and having to enter it manually using "set args" (Painful...).
Is this even possible? Can gdb's args be automatically linked to the program's args and if so, can it be done through a gdbserver connection?
Thanks,
XL600
What I'd like to do is run my target code on another server with gdbserver and its args there using the bash script front ends that generate the args,
I am not sure I understand the difficulty. You could do:
gdbserver :1234 a.out $(generate_args.sh)
or
gdb --args a.out $(generate_args.sh)
Related
I am trying to launch a legacy application in GDB, and it requires that it's argv[0] value not contain anything other than alphanumeric characters.
Whenever I launch the program in GDB it seems that it expands the name to be the full path before running the program, so I get an error like (because it can't deal with the slashes):
"Cannot find /home/user/myapp ..."
Is it possible to run a program in GDB with a relative path, so that it will just see "myapp"?
Gdb normally runs target commands using the shell command line
exec program_pathname program_arguments
But it has a set exec-wrapper command that will change this to
exec exec_wrapper program_pathname program_arguments
The exec_wrapper is often another command, but it can be an option that the exec command accepts.
Many shells (bash, zsh, ksh93) support a -a option to the exec command to set argv[0].
So, if your shell supports exec -a, you can do the following to invoke /home/user/myapp with argv[0]==myapp:
(gdb) set exec-wrapper -a myapp
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
Background info: The C++ program(LAMMPS - an open source) takes in a input script that has all the commands to be executed. The executable is named "lmp_fedora", input script named "in.hit". The program's run command "./lmp_fedora < in.hit"
My Problem: I am trying to debug one of the .cpp files in LAMMPS.
My Attempts: 1. I tried "gdb lmp_fedora < in.hit", but it failed. 2. Also tried to find the pid of the running program using ps aux, but wasn't sure which id it was.
My Question: How do you debug a input script(that has commands linked to c++ project) using gdb?
You use the gdb run command:
$ gdb lmp_fedora
(gdb) run <in.hit
From the help:
(gdb) help run
Start debugged program. You may specify arguments to give it.
Args may include "*", or "[...]"; they are expanded using "sh".
Input and output redirection with ">", "<", or ">>" are also allowed.
With no arguments, uses arguments last specified (with "run" or "set args").
To cancel previous arguments and run with no arguments,
use "set args" without arguments.
When you say gdb foo < bar that means bar is input to gdb, not to foo.
I think what you want to use is the gdb command set args.
How do I give commands to run before starting gdb debugging in Eclipse ?
Actually I want to execute few scripts that set environment variables (export vars) and execute a bunch of other programs before gdb process is launched from eclipse to debug my program.
I tried doing the following in debugger tab option:
<command> && <path-to-gdb-executable>
But I got the error that eclipse cannot execute gdb as given in above statement.
Please help - I actually want to execute a script called "before-launch-commands.sh" before debugging is started by gdb. I am trying to execute a cpp program under eclipse kepler.
Thanks.
The Eclipse Debug Configurations can already setup environment variables for you. I'm going to assume that that isn't sufficient, or you'd have already done it.
The first thing to do is create a new script, wrapped-gdb.sh:
#!/bin/sh
# Export any variables we need.
# Note that '.' (dot) is like an "include" statement.
. /path/to/before-launch-commands.sh
# Run GDB using the parameters passed in
exec /path/to/gdb "$#"
Next, set that script executable:
chmod +x /path/to/wrapped-gdb.sh
Finally, go to the Debugger tab in the debug configuration dialog, and in the box marked "GDB Debugger" enter /path/to/wrapped-gdb.sh.
When you launch your debug session it should now Do The Right Thing.
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