i'm new to GDB so hope it's a fair question...
i would like to run a script with GDB that get a coredump file and save the BT of all threads into a file.
my problem is to operate the GDB.
i tried:
GDB <exe> <core file> --command = my_script
where my script is:
thread apply all bt
that doesn't work of course.
is there another way to operate GDB with a certain command?
thanks alot
Nurit
Yes, do not put spaces around the =.
gdb <exe> <core> --command=my_script
Alternatively, just do this:
gdb -ex 'thread apply all bt' <exe> <core>
Related
I want to write a script that will read a process memory, and display its contents with some modification/format.
It would be create if i could run a c program inside gdb and send gdb commands from this program. Do you know if it is possible ?
It would be great if i could run a c program inside gdb and send gdb commands from this program.
That's easy:
(gdb) shell /tmp/a.out > /tmp/gdb.script
(gdb) source /tmp/gdb.script
If your gdb is built with Python support, much better scripting support is available. Start here.
I am running someone's code and the code crashes on a specific dataset, but the crash message as-is is not informative. I cannot call GDB and then wait (for GDB) to pass r to it (things are running on a cluster). Is there a way to pass r to GDB in the runtime by default, something like the following?
gdb r ./run
You can load your program in GDB, like:
$ gdb your_program_name
and then attach to process which you want to debug
attach pid
You may use a commands file. Write all the commands you want to execute sequentially in the file. And use that file to pass the command to GDB with input redirection:
echo "r" > cmds
gdb r --args ./run -arg1 -arg2 -arg3 < cmds
I am a beginner and got some trouble in RE.
I have an ELF 'bomb' and an unknown file 'model.abc'.
The correct way to run bomb is:
bomb model.abc
Now I want to use gdb to see the value of some addresses when running it. Can any one help me?
First start gdb from a shell prompt:
$ gdb bomb
Then run your program from the (gdb) prompt with the command line you want:
(gdb) run model.abc
You need to launch your program this way because gdb doesn't allow you to specify command line arguments for your program on the gdb command line.
Another, more convenient way of debugging a program with arguments:
gdb --args program <arguments>
If you don't have symbols, you'll have to start from the entry point. To figure our where it is, use:
(gdb) info file
Symbols from "/.../tesprog".
Local exec file:
`/.../tesprog', file type elf32-i386.
Entry point: 0x804abc0
Then you can set breakpoint on it before running:
break *0x804abc0
Note that the entry will be most often the library startup code (ctr0.s), it might take a while to get to the actual code written by the programmer.
I am currently debugging a program with gdb.
I have to start gdb over and over again and do the same steps:
set a breakpoint,
run,
print a variable,
quit
Is there a way to let gdb do that automatically for me? Probably a script that could be attached as a parameter?
Thanks in advance!
You can do it either by -x file option or by -ex command option. From Gdb manual:
-command file
-x file
Execute commands from file file. The contents of this file is evaluated exactly as the source command would. See Command files.
-eval-command command
-ex command
Execute a single gdb command.
This option may be used multiple times to call multiple commands. It may also be interleaved with `-command' as required.
gdb -ex 'target sim' -ex 'load' \
-x setbreakpoints -ex 'run' a.out
The interwebs differ on whether the name of the file is .gdbrc or .gdbinit, but GDB will read this file from your home directory on start-up, and it can give any GDB command (including setting breakpoints).
Also check out http://www.andrews.edu/~seidel/gdb.help
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