After the source file is movedGdbWhy code is not displayed
Problem
We start with the simplest C language program. The source file main. c is in the gdb folder of the user directory.
Florian @ florian-pc :~ /Gdb $ cat main. c
Int main ()
{
Return 0;
};
Compile the source file as main (debugging option-g is required), move main. c to src/main. c, and debug main.
Florian @ florian-pc :~ /Gdb $ gcc main. c-o main-g
Florian @ florian-pc :~ /Gdb $ mv main. c src/main. c
Florian @ florian-pc :~ /Gdb $ gdb main
(Gdb) B main
Breakpoint 1 at 0x8048397: file main. c, line 3.
(Gdb)List
1 main. c: the file or directory does not exist.
In main. c
In gdb, the source file main. c cannot be found when you use the list command to view the source code.
Exploration
Because the DWARF debugging format is not clear, I thought that the executable program compiled using the debugging option contains the content of the source file, no matter whether the source code exists or not, all executable programs can be properly debugged. However, we can see from the above example that this is not the case.
We can make a simple assumption: since the location of the source file is moved, gdb cannot find the location of the source file. It is estimated that the debugging section of the executable file does not store the content of the source file, but path information.
Move main. c back, re-compile, generate the target file main. o, and view its segment information.
Florian @ florian-pc :~ /Gdb $ mv src/main. c main. c
Florian @ florian-pc :~ /Gdb $ gcc-c main. c-o main. o-g
Florian @ florian-pc :~ /Gdb $ objdump-s main. o
Main. o: file format elf32-i386
Contents of section. text:
0000 5589e5b8 00000000 5dc3 U ......].
......
Contents of section. debug_str:
0000 6d61696e 2e63002f 686f6d65 2f666c6fMain. c./Home/flo
0010 1099616e 2f676462 00474e55 20432034Rian/gdb. Gnu c 4
0020 2e342e35 006d6169 6e00. 4.5.main.
......
We found that there are two obvious string information in the. debug_str segment.
(1)/home/florian/gdb: It looks like the absolute path of the source file.
(2) main. c: the name of the source file.
Verify
We will move main. c to the src directory and compile it again to see how the string information has changed.
Florian @ florian-pc :~ /Gdb $ mv main. c src/main. c
Florian @ florian-pc :~ /Gdb $ gcc-c src/main. c-o main. o-g
Florian @ florian-pc :~ /Gdb $ objdump-s main. o
Main. o: file format elf32-i386
Contents of section. text:
0000 5589e5b8 00000000 5dc3 U ......].
......
Contents of section. debug_str:
0000 2f686f6d 652f666c 6f316961 6e2f6764/Home/florian/gd
0010 6200474e 55204320 342e342e 35007372B. Gnu c 4.4.5.Sr
0020 632f6d61 696e2e63 006d6169 6e00C/main. c. Main.
The two strings in the. debug_str segment are changed.
(1)/home/florian/gdb: the absolute path of the current directory when the gcc command is executed.
(2) src/main. c: This string is the relative path of the source file to the current directory.
Merge the two directories to obtain the absolute path of the source file:
/Home/florian/gdb/src/main. c
Conclusion
It can be seen that the executable file generated by debugging is not the content of the source file, but the absolute path information of the source file. Other debug segments defined in the DWARF debugging format (see here) Save the correspondence between the binary code and the source file line number, so that when the gdb list command is running, it actually reads the row number information in the executable file and displays the code content of the source file. This is why the list command cannot find the source file after the source file is moved.
Here, we can also understand the fact that when the source file path of the source code directory changes, if you need to debug the executable file, you must re-compile it.
Similar problems exist not only in the gdb list command, but the objdump-S command is used to cross-display the disassembly code and source code, which will also be affected by moving source files.