In this post I will explain another way you can do it.
We are going to load debuging information from a file that was generated by our executable just before it was stripped off..
I am going to use the same source and environment settings that I used in my earlier post:
- released.c: source code of the program we wish to debug (listing 1).
- ~/estudo/: Source code of our program will be put here.
- ~/local/bin: The stripped off version of binary program will stay here.
- ~/local/symbols: In this place are all files that contain debugging information.
#include <stdio.h> #include <stdlib.h> int division(int a, int b); int m; int main(void) { int i; int j; printf("vou setar i\n"); i = 10; printf("vou setar j\n"); j = 1; printf ("i = %d, j = %d\n", i, j); m = division(i, j); printf("m = %d / %d = %d\n", i, j, m); return 0; int division(int a, int b) { return a / b; }
Listing 1 - sample program source code
Let's start:
1 - Create your program with debug information. In our sample:
gcc -g -o release release.c <ENTER>
2 - Now we will generate a file that will contain only debug informations. You generate this file by issuing this command:
objcopy --only-keep-debug <ENTER>
In our sample:objcopy --only-keep-debug release release.sym <ENTER>
The choice of .sym as an extension for the debug info file is totally arbitrary. You can use whatever you wish to.
3 - You remove debugging information:
strip -s release <ENTER>
4 - Move file release to ~/local/bin/:
mv release ~/local/bin <ENTER>
5 - Move file released.sym to ~/local/symbols/
mv release.sym ~/local/symbols <ENTER>
6 - Go to directory ~/local/bin
cd ~/local/bin <ENTER>
7 - Run GDB:
gdb ./release <ENTER>
8 - Try list command to see that release executable file doesn't have symbols in it.
Figure 1 shows us what I said.
9 - Let GDB to load symbols from symbols file named release.sym. This file has all symbols that we need to debug. You achieve this by issuing the following command:
add-symbol-file ~/local/symbols/release.sym <ENTER>
From now on you can debug your program as usual.
Figure 2 shows us that debugging symbols where imported successfully and that now the list command shows us the program source code.
As you can see in figure 3, I set a break point at line 17 and I ran the program that stopped there. Then I printed i variable. It is possible just because symbols were loaded.
You can see that this method to load debug symbols is easier than the previous one presented in the post How to load debug symbols with GDB.
My friend Jumpi complained that it is not the unix way to debug applications that just don't have debug information by loading a separated file. We have core files to help us to debug the application in our host.
I agree with him that it is unusual to debug this way, but it may be useful.
The idea behind this method (and behind the previous one) is similar to that used by MS with .pdb files.
It will allow you to save disk space on your host because you can keep only stripped versions of your applications and libraries in it. It is especially important to embedded systems.
At the same time it let you have a collection of symbol files stored at some place (say, a DVD disc or another server). When (and if) you need to do a debug session
I hope this post will make your life easier.
2 comentários:
Congratulations for the awesome GDB posts! I'm beginning to understand the relation between symbols and code in Linux world, and it seems even more powerful and flexible than the ms way.
Now I got curious about the "traditional" way to do something. How to debug core dumps in a live debugging scenario? By example: you're debugging a piece of code in the server, and you can't just stop some processes in order to step into the code. The solution is to generate core dumps all the time to see processes information?
[]s
Great how-to! It is definitely useful for any linux C developer.
Thank you!
For Wanderley Caloni: gdb can attach a live processus, you just have to type:
gdb ./your_binary PID
Postar um comentário