I have more than 10 symbol files to add at runtime in gdb
add-symbol-file build/i386//fat 0x80a211dc
add-symbol-file build/i386/fs/cd9660/cd9660 0x00000ac0
add-symbol-file build/i386/fs/ntfs/ntfs 0x00001518
Adding all files one by one in gdb is very time consuming job & takes more time. Does gdb have only one command to add all files at proper place?
I used gdb command
set debug-file-directory
but it does not work, so plz help
There's no built-in command to do what you want.
However, you can automate gdb using either the built-in command language (the "CLI") or using Python. I don't know how you find those addresses, but the idea would be to automate that with a script.
For the CLI this automation could perhaps be done via the shell command, writing a sequence of add-symbol-file commands to a file, which you'd then source.
For Python you can simply write a program that eventually uses gdb.execute to evaluate the add-symbol-file commands you need.
Related
There is gdb.lookup_type("SomeType") in GDB python API as listed blow, but I cannot find a way to get the source file and line number where the type is defined, much like what the GDB command info types ^SomeType$ does. Is it possible via GDB python API without invoking into the info types command?
https://sourceware.org/gdb/onlinedocs/gdb/Types-In-Python.html#Types-In-Python
I heavily used gdb before, and now give lldb a shot. I like gdb's start command very much, but I can't find the equivalent one from lldb's manual. Now I can only use "b main" followed by run compound instead. So just curious whether there is an equivalent one in lldb? Or I can only use the compound of "b main" and run commands as a work-around.
You are correct, lldb doesn't have a dedicated start command. The stated motivation for that command is that gdb supports lots of runtimes that don't use a "main" symbol. That makes determining where user code begins non-trivial, and it's useful to have a command that figures that out for you. We haven't had a need for that in lldb yet.
If you always use start to run programs in gdb, then you can just set a breakpoint on main in your ~/.lldbinit file. That will get copied to any new targets that get made in your lldb session, and run will behave exactly like start (for runtimes that use a main symbol).
If it's something you would use a lot but not always, you could make your own version fairly easily using the python extension point in the command interpreter:
https://lldb.llvm.org/use/python-reference.html#create-a-new-lldb-command-using-a-python-function
Also, feel free to file an Enhancement Request with http://bugs.llvm.org.
I am new to Linux space.
My project creates 'so' (akin to our dll's) which is used by an executable.
Currently to debug, I invoke gdb -tui Which puts me into the gdb terminal where I put break points and do the r with parameters ... and debug.
Everything was fine, until now where the entire architecture has been changed.
Now to run our code, we execute a command
$ java -jar ... and a lot many parameters.
The jar files etc do not belong to us.
I am yet to find out what executable is called, or the code flow.
Question :
Is there a way to invoke gdb command from within my source code ?
say
MyClass::myFunc()
{
some calls
<THE GDB COMMAND>
What I am looking at is, once I place my 'so' in the path and execute the said java command, the gdb is invoked the moment it hits my function.
The solution provided here wasn't clear.
Invoke and control GDB from c++
I'm trying to debug a CUDA program, but when I'm launching gdb like so:
$ gdb -i=mi <program name>
$ r <program arguments>
I'm getting:
/home/wvxvw/Projects/cuda/exercise-1-udacity/cs344/HW2/hw:
error while loading shared libraries: libcudart.so.5.0:
cannot open shared object file: No such file or directory
Process gdb-inferior killed
(formatted for readability)
(I'm running gdb using M-xgdb) If that matters, then CUDA libraries are in the .bashrc
export PATH="/usr/local/cuda/bin:$PATH"
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/cuda/lib64"
error while loading shared libraries: libcudart.so.5.0
This error has nothing to do with GDB: your executable, when run from inside GDB, can't find the library it needs.
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/cuda/lib64"
GDB runs your program in a new $SHELL, so that should have worked. I wonder if there is some interaction with emacs.
In any case, this:
(gdb) set env LD_LIBRARY_PATH /usr/local/cuda/lib64
(gdb) run
should fix this problem.
Update:
as I've mentioned it before, ld path is set properly
No, it isn't. If it was, you wouldn't have the problem.
Now, I don't know why it isn't set properly. If you really want to find out, start by running GDB outside emacs (to exclude possible emacs interactions).
If the problem is still present, gdb show env, shell env, adding echo "Here" to your ~/.basrc, etc. should help you find where things are not working as you expect them.
I've had this problem as well. One way to look at it is that even if the LD_LIBRARY_PATH variable is correct when you enter show env into gdb, it may not be correct when you actually execute the program because gdb executes $SHELL -c <program> to run the program. Try this as a test, run $SHELL from the command line and then echo $LD_LIBRARY_PATH. Is it correct? If not, then you probably need to add it to your rc (.tcshrc in my case).
I had a similar problem when trying to run gdb on windows 7. I use MobaXterm to access a Linux toolbox. I installed gdb separately from http://www.gnu.org/software/gdb/ . I got it to work by making sure gdb could find the correct .dll files as mentioned by Employed Russian. If you have MobaXterm installed the .dll files should appear in your home directory in MobaXterm/slash/bin.
gdb however did not recognize the LD_LIBRARY_PATH variable. For me, it worked when I used the PATH variable instead:
(gdb) set env PATH C:\Users\Joshua\Documents\MobaXterm\slash\bin
(gdb) run
I would think using PATH instead of LD_LIBRARY_PATH might work for you provided you put the correct path to your library.
gdb is looking for a library, so why are you concerned with the include path? You may want to try to set the gdb option "solib-search-path" to point to the location of the libcudart.so.5.0 library.
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.