Is there a way to get the value of all variables in c during each execution step of a program.
Some other method except GDB.
Thanks in advance
-Sahil
The debug statements you are talking about are the printfs marcadian pointed out, which you will have to do manually, I don't know any other way in which you can tell the compiler to build the executable such that it will automatically print the variables except from GDB. All you have to do is compile the file like this : gcc -g file.c -o output.o. The -g flag constructs the table for gdb, have a look at some tutorials online http://www.cprogramming.com/gdbtutorial.html on how to use it afterwards.
Edit: info locals will be quite useful to print all the local ones
Related
I am looking for help with GDB to reverse engineer shared library written in C that is preloaded in /etc/ld.so.preload.
Current library hooks accept() call if source port is correct it returns reverse shell back to user.
Strings command doesn't give out source port, so my target is to try to find it within GDB.
Program consist of two files headers.h where I have my definitions and variable #define SECRET_PORT 11111
source.c contains accept hook with reverse shell.
My problem is I cannot figure out a way how to retrieve PORT within GDB - I can load mylib.so within gdb and run: info functions to see whats inside - I can see accept function but when I try to disass accept I only get instructions that I barely can understand.
Problem when I run mylib it gives out SIGSEGV (maybe thats the reason I cannot see variables) there is no main function where to set break and if I do set it on function accept is still gives SIGSEGV error.
I tested with starti instead of run then I got Program stopped 0xSOMEADRESGOESHERE in deregister_tm_clones() I don't even know if this is correct way to test .so file. maybe there are some oser switches.
Im thinking I need to find a way how to set BP in HTONS() checking function where if statement compares source port and extract values from there but so far no luck.
p.s. when mylib is loaded in gdb there is message No debugging symbols found. So I cannot run like list accept or anything like that to view a source.
Compilation code gcc -Wall -shared -fPIC mylib.c -o mylib.so -ldl
Im thinking I need to find a way how to set BP in HTONS() checking function where if statement compares source port and extract values from there
You don't need to do that -- the instructions will be the same whether you run the application, or disassemble the function without running.
Compilation code ...
So you are trying to reverse-engineer the library for which you have a source?
That makes it very easy to find the constant you are looking for.
Start by setting the constant to easily recognizable value, e.g. 0x12131415. Compile the library and disassemble it. Look for your constant.
If you don't see it, save the disassembled output, and rebuild the library with a different value, e.g. 0xA1B1C1D1. Disassemble it again and compare to previous disassembled output. It should be easy to spot the difference.
P.S. If you really want to debug this library with a live process, do this:
gdb ./myprog
(gdb) set env LD_PRELOAD /path/to/mylib.so
(gdb) run
At this point, you should be able to set breakpoints and observe your library "in action".
Ok managed solve this with a help
when running GDB on shared library You will have to check hex value for 11111 and it should be 2B67 so in registers this will become something like 0x2b67 & it will be passed to htons() as check for source port.
So let's assume I didn't have the source code I could still run: gdb -q *.so
then: info functions and see with disass functionNameGoesHere where some accept / htons calls are made. Correct value should be found right above htons line.
Then decoded hex to dec and thats how You can find it.
This took some while to figure out as I coudn't set BP's.
Again thanks for input from community! Cheers
I'm having issues with a c program that I want to debug.
I would like to know how to get a file that contains every lines of my executable, so I can later set breakpoints with gdb in it.
Thanks :)
For GCC specify -g when compiling.
More here: https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
I'll try to simplify and make clear my other question here. I am basically trying to use gdb to see where myfile.c is segfaulting. However, I cannot directly examine myfile.c under gdb, but there I am given a driver program (vdriver) that will randomly test the methods I have provided for it in myfile.c
So, after compiling with "gcc -ggdb -c vdriver.c myfile.c myfile_depends_on_this.c" I run "gdb vdriver" until it segfaults. At that point, typing "list *$eip" just prints "No source file for address 0x804something"
I am also confused about how I should "gcc -ggdb -c etc,etc" for header files such as myfile.h and myfile_depends_on_this.h, because I'm not sure whether (or how) it should be included in the command or not.
But anyway, is there any way of fixing the "No source file for address" problem?
Here is how I understand your question (it's not quite clear to me):
how to debug after a segfault?
how to compile .h files?
As to
After crashes, you will no longer be in execution context and so no longer be able to use the regular debugging commands. Instead, gcc will produce a core file. You probably need to allocate space for a core file first, then debug, as described in (eg):
http://www.network-theory.co.uk/docs/gccintro/gccintro_38.html
.h files are not included in the list of files to be compiled. They are referenced from within your .c file with the usual #include (or #include "file.h") semantic
If this wasn't your question, kindly elaborate.
While debugging a C program in gdb I have a breakpoint in a for loop. I cannot print the value of "i" ( I get : No symbol "i" in current context.). I can print the value of all the other variables. Is it normal?
Here is the loop:
for (i=0; i < datasize; i++){
if ( feature_mask[i] > 0 ){
k = feature_mask[i] - 1;
if (neighbors[k][nmax-1] != 0){
neighbors[k][nmax-1] = bvalue;
feature_mask[i] = -feature_mask[i];
}
}
}
It has probably been optimised out of your compiled code as you only use feature_mask[i] within the loop.
Did you specify an optimization level when you called your compiler? If you were using gcc, then just omit any -O options and try again.
I encountered this issue recently. I compiled GCC 5.1 and then used it to compile a C++11 codebase. And, although I could step through the program's code in gdb, I couldn't print the value of any variable, I kept getting “No symbol "xyz" in current context” errors, for every variable.
I was using gdb 7.4, but the latest version available at the time was 7.9. I downloaded the latest version of gdb and compiled it (using GCC 5.1) and when using gdb 7.9 I was able to successfully inspect variable values again.
I guess the debug information of GCC 5.1 is incompatible with gdb 7.4.
Make sure the program is compiled without optimization, and with debugging information enabled. It's quite likely that the loop counter ends up in a register.
Check your optimization options. It's possible the GCC could replace the variable with a pointer into feature_mask.
You can try declaring i as volatile. That will prevent some compiler optimizations (and hopefully make i visible inside the debugger).
In case anyone else is using Google's Bazel build system for your project, I'd like to add that if you cannot print any variables from gdb, it may be because you need to properly add the -ggdb and -O0 (update: use -Og instead of -O0 use -O0 over -Og) C build flags using the --copt= option, INSTEAD OF using the --per_file_copt= option. In my case, although they both built and ran just fine, only the --copt= technique allowed me to fully use gdb and print variables, whereas the --per_file_copt= one also allowed me to use gdb but would NOT allow me to print variables.
Note: in the below examples, just replace test with build if you do NOT need to run the unit tests as well.
UDPATE: it turns out, you should prefer -Og over -O0 when doing debugging, so I'm updating these examples accordingly. See here: What's the difference between a compiler's `-O0` option and `-Og` option?.
So, do this:
time bazel test --copt=-ggdb --copt=-O0 \
//my/build/folder1/... //my/build/folder2/...
INSTEAD OF this:
time bazel test --per_file_copt=//my/build/folder1/...,//my/build/folder2/...#-ggdb,-O0 \
//my/build/folder1/... //my/build/folder2/...
...in order to be able to print variables from within gdb.
Again, both of the above techniques build and run just fine, and both allow me to run and use gdb, but only the first one actually allows me to use gdb to its full extent.
Lastly, if the first command above still doesn't work, try adding the --strip=never Bazel flag described here to prevent Bazel from ever stripping debugging information. Now the command will look like this:
time bazel test --copt=-ggdb --copt=-O0 --strip=never \
//my/build/folder1/... //my/build/folder2/...
Reference documentation:
--copt=:
https://docs.bazel.build/versions/master/command-line-reference.html#flag--copt
[better, with examples] https://docs.bazel.build/versions/master/user-manual.html#flag--copt
--per_file_copt:
https://docs.bazel.build/versions/master/command-line-reference.html#flag--per_file_copt
[better, with examples] https://docs.bazel.build/versions/master/user-manual.html#flag--per_file_copt
--strip=never:
https://docs.bazel.build/versions/master/user-manual.html#flag--strip
[my own Q&A] Prefer -Og over -O0 -O0 over -Og for debugging: What's the difference between a compiler's `-O0` option and `-Og` option?
I've compiled my C program using gcc 4.4.1 using the flag -g, but when I try to step through one of my functions in gdb version 7.0, I get the message:
"Single stepping until exit from function _DictionaryTree_getNodeList,
which has no line number information."
Can someone tell me why this is happening?
Just guessing, but is _DictionaryTree_getNodeList in another file that wasn't compiled with -g?
I had the same problem but in my case adding -g to the compiler wasn't enough so I used -ggdb as suggested by Manav.
In my case, the problem was version skew between gcc and gdb.
After landing here from search and none of these answers fit my situation, I figured out that (because of aliases / symlinks / Makefile / environment variables) I was accidentally using a newer GCC (4.8.x) and an older GDB (7.2). Stepping up to a newer version of GDB (7.8) fixed the problem. For some reason, using a newer GCC and older GDB didn't work.
I had this error message too but the source of my problem was different. If anyone is still having any problems, make sure you have #include <stdio.h> in your file, with the the appropriate brackets around stdio.h (the text message would not show up if I had it around stdio.h).
I had the same issue, when I compiled a file using -g option and without -g option.
For one of the file, the gdb showed line number without any issues(even when it was compiled without -g option)..
And for the other file, I had to explicitly mention -g flag...
Any ideas as to whether the source file could be loaded at run time in
GDB with cross referencing would be good solution... by mapping the
lines to the addresses :D.
I had this issue because I was debugging a shared library without pointing LD_LIBRARY_PATH to correct location with debug endstates.
you can use
export LD_LIBRARY_PATH=<location of the debug build of the .so file>:$LD_LIBRARY_PATH
Hopefully this is helpful to someone
I had the same trouble despite I was already compiling with -g2. Changing it to -g3 did the trick.
Im using GBD 12 , im not able to use any of these flags and options , also im debugging .exe file , so yes I used makefile