I have compiled my own glibc, which produced libc.so. I loaded the libc.so file in gdb by doing gdb -q ./libc.so. However, when I try to find the location of a function by doing list function_name, I get the error message, No line number known for function_name. Note that I use the -g flag for compiling glibc. How can I solve this problem?
Can you even debug a .so by itself? What I would try is to do is gdb executable_using_my_libc. Then this should load glibc and so on.
Related
I have a C library which is created with
cc -fPIC -g -O3 -c -o obj/my_lib.o my_lib.c
g++ -shared -Wl,-soname,libmy_lib.so.1 obj/my_lib.o -o libmy_lib.so.1.8.0
This library is packaged into debian packages with dpkg-buildpackage producing libmy_lib1-1.deb, libmy_lib1-dev-1.deb, and libmy_lib1-dbgsym-1.ddeb. Installing all of those packages, I can then compile/link a simple test program that calls into the library. This works. Running the test program works.
However, when I run GDB on the test program (on the same computer), I see
gdb$ break main
Breakpoint 1 at 0x87e: file test.c, line 10.
gdb$ info sharedlibrary
No shared libraries loaded at this time.
gdb$ r
Starting program: /tmp/a.out
Breakpoint 1, main () at test.c:10
10 my_library_func();
gdb$ info sharedlibrary
From To Syms Read Shared Object Library
0x00007ffff7dd5f10 0x00007ffff7df4b20 Yes /lib64/ld-linux-x86-64.so.2
0x00007ffff7bac9a0 0x00007ffff7bad438 Yes /usr/lib/x86_64-linux-gnu/libmy_lib.so.1
0x00007ffff74532d0 0x00007ffff75cbc3c Yes /lib/x86_64-linux-gnu/libc.so.6
0x00007ffff709fa80 0x00007ffff715e2f5 Yes /lib/x86_64-linux-gnu/libm.so.6
0x00007ffff6e7eac0 0x00007ffff6e8f36d Yes /lib/x86_64-linux-gnu/libgcc_s.so.1
(*): Shared library is missing debugging information.
gdb$ s
my_library_func () at my_lib.c:299
299 my_lib.c: No such file or directory.
As you can see, GDB knows about the debug symbols for the library. However, it does not know about the source file for the library. How should I running GDB to it can resolve the C source code?
You need to also tell gdb where the source files are. Which means you also need the source files, not just the debugging symbols.
It's important that the sources you download are the actual ones used to compile the library, because debugging information only contains filename and line number. If you give gdb a file where the line numbers don't correspond (a different version, for example), the source lines printed by gdb will be very confusing. It has no way to know they are wrong. You should be able to use the src deb with the same version number as the library debs.
Once you have the source files, tell gdb where to look for them with
directory /path/to/source/files
You can specify several paths. Read help directory inside gdb.
Since you'll need to do this often, put that line into a gdbinit file. You'll probably want to use .gdbinit in your current directory, but .gdbinit in your home directory might also be a possibility. Gdb uses both.
If you're working with a library whose source is spread over a subdirectory tree, you might find it useful to set a substitution path:
set substitute-path /your/file/path /original/file/path
Again, more help is available with help set substitute-path.
GDB searches a number of default directory paths to locate the specified sourcefile. You can add paths using the directory command: https://sourceware.org/gdb/current/onlinedocs/gdb/Source-Path.html
I am having trouble getting the debugger to work properly when setting up clang on my Windows 10 machine. Compilation seems to work OK, at least for the simple "hello, world" program I tried. However, when I try to run the lldb or gdb debuggers on this test program (or any other program I tried), it does not recognize function names.
Here's my C program code:
#include <stdio.h>
int main(void) {
puts("Hello, world!");
return 0;
}
Nothing too spectacular here, I know. I'm compiling with the following command:
> clang -g -O0 hello.c -o hello.exe
I then try to run the debugger:
> lldb hello
(lldb) target create "hello"
Current executable set to 'hello' (x86_64).
(lldb) b main
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
(lldb) r
Process 12156 launched: 'C:\Users\********\Projects\clang-test\hello.exe' (x86_64)
Process 12156 exited with status = 0 (0x00000000)
(lldb)
Apparently the symbol "main" was not recognized, and the program did not halt at the start of the "main" function but ran to completion (in a different console window, hence no program output here).
How do I get debugging symbols to work? In a different stackoverflow answer I found that adding compiler options "-g -O0" should do the trick, but as you can see that does not solve the problem for me. I also found a different stackoverflow answer about how to set up debugging if the code is not in the same directory as the executable, but that is not relevant to my case: the current working directory is the same as the directory with the code and executable in them.
Some version information:
> clang --version
clang version 9.0.0 (tags/RELEASE_900/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin
> lldb --version
lldb version 9.0.0
The "-g -O0" options you provided should indeed let the debugger know all the symbols it needs from the executable.
Therefore, I suspect the problem is elsewhere, perhaps with your terminal, or your version/implementation of LLDB.
Are you using the windows cmd.exe commandline ? or something else, like Powershell ?
I've never managed to get debuggers working properly in those environments, but it was much easier with Cygwin, which is a bash shell for windows (it creates a "simulated" linux environment within its install folder, so you have all the /usr,/bin,/etc folders a bash shell needs)
This way you can actually use gdb the way you would on a UNIX system.
If the above method sounds like more of a hassle than a time-gain, then yeah I would recommend another debugger altogether, like the Visual Studio debugger.
In fact, maybe a memory-analysis tool like Dr.Memory can give you what you need
I compile such code by GCC (v7.1.0) (command line below).
int func()
{
return 0x1234;
}
int main()
{
func();
return 0;
}
gcc .\001_simpleMain.c -O0 -m64 -g
After compilation I run WinDbg (10.0), open executable (Ctrl+E), program is loading. Breakpoint is hit on start process everthing is ok.
After it I want to open source code (Ctrl+O) and try to put breakpoint inside func method.
WinDlg tells me:
*** ERROR: Module load completed but symbols could not be loaded for G:\Examples\Gcc\a.exe
Why it is not working? Should I change compilation param? MY CPU is AMD64
Since you're using Windows with WinDbg you need the proprietary PDB files, which contain the debugging information for debugger tools that come from Microsoft.
GCC will generate debugging information that can be used by the gdb debugger (well known in Linux) for example.
gcc -g:
Produce debugging information in the operating system’s native format (stabs, COFF, XCOFF, or DWARF). GDB can work with this debugging information.
If you are using MinGW or Cygwin already you can use gdb from there because it's available in the MinGW/Cygwin environment. If not there are several gdb implemenations for Windows available.
Once you have built debugging files according to #Andre Kampling's instructions, you'll first need to convert them into PDB format. But even then, WinDbg will likely still not find them.
The executable has some data which points to the PDB file. Since you built in on Linux, that will be a Linux path which is not available on your Windows system.
Therefore, you need to set up your symbol path correctly so that WinDbg knows where you put them.
Basically you'll need
0:000> .symfix c:\symbols
for the Microsoft symbols and
0:000> .sympath+ c:\path\to\your\symbols
and then instruct WinDbg to load them again
0:000> .reload /f
0:000> ld*
I have been asked in an interview how can you debug segmentation fault in C program using GDB.
I told them we can compile our program with -g option so as it add debugging information to binary file and can read core dump file but then interviewer told me if he we have 3 to 4 files compiled together but one of them causing segmentation fault then how do we debug in GDB?
$ gcc -ggdb s1.c s2.c s3.c -o myprog
$ gdb myprog
(gdb) run --arg1 --arg2
GDB will run the program as normal, when the segmentation fault occurs GDB will drop back to its prompt and it will be almost the same as running GDB with a core file. The major difference is there are some things you cannot do/print with a core file that you can when the program has crashed inside of GDB. (You can use print to call some functions inside the program, for example.)
You can also attach to an already running program using gdb --pid <the programs pid>.
Either with a core file or with one of the methods above, when you have the GDB prompt after the crash, type backtrace (or bt for short) and GDB will show you the stack at the time of the crash, including the file names and line numbers of each call and the currently executing line.
If you are working under Linux the easier way to find segmentation fault is by using the tool named VALGRIND: http://valgrind.org/ .
You just need to compile your code with -g flag and then run ./valgrind .
Then you will know exactly in which function and in which line of code there is an error-uninitialized memory/memory read out of allocated space or sth.
You just run the program under gdb, and the debugger with catch the SIGSEGV and show you the line and instruction that faulted. Then you just examine the variable and/or register values to see what's wrong. Usually it's a rogue pointer value, and trying to access it with GDB will give and error, so it's easy.
And yes, recompiling everything with -g would be helpful. The interviewer probably wanted you to describe how you'd figure out which file had the fault (gdb just tells you when it catches the signal) and just recompile that one with debug info. If there's 20,000 source files that might be useful, but with 3 or 4 files, what's the point? Even with larger projects, you usually end up chasing the bad pointer through 10 functions and 5 files anyway, so again, what's the point? Debug info doesn't cost anything at run time, although it costs disk space in an installation.
compile the code in normal way by giving gcc filename
you will get a .out file, start running that and get the process id by giving ps -aef | grep filename.out
in a another window type gdb and enter,inside gdb prompt give attach processid (processid you will get from above command),give c to continue.once the execution finishes give "bt" inside gdb.you will get the place where the segmentation is occurring.
Sounds like they are looking to set it up so that you can step through the code as it is running, you can do this with the command line version or I think you can get a GUI for GDB.
one can use the following steps to debug segmentation fault using gdb
$ gdb <exec name >
$ r //run the pgm
$ where
$ f <1> <0> //to view the function n variables
$ list
$ p <variable>
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