![]() In the case where you have debug info in a separate file from the binary (common with various distribution's package managers), one objfile will be instantiated for the executable file (gdb will still be able to read some symbols from it) and another one will be for the debug info file. If mybinary loads some shared libraries, gdb will read symbols from them as well, and will instantiate one objfile for each. Therefore, mybinary itself will be represented by one objfile instance. For gdb, an objfile consists of one file from which it reads symbols or debug info. The first thing gdb needs to do is to create an objfile object that represents mybinary. ![]() The symbol-file command makes gdb forget about any previously loaded symbols (FIXME: only for that inferior? for all of them?) and replaces them by those coming from the specified file. This includes translating a symbol (function or variable name) into an address, a line number into a code address or vice-versa, etc. symbol-file indicates that gdb should use this file as a reference for symbols and debug information. exec-file does the necessary to open the executable and sets it as the current executable for the selected inferior. The file command is essentially the exec-file command followed by the symbol-file command. This focusses on what is probably the most common case, Linux on x86 with DWARF debug info. Obviously, gdb supports a vast combination of platforms, architectures and debug info formats. The purpose of this page is to take a look at what happens when using the file command, more precisely what algorithms and data structures gdb uses to parse and store information about symbols.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |