On May 27, 2013, at 5:49 PM, Michael Sartain <[email protected]> wrote:
> The elf files we are debugging on Linux have split the debug information from > the main binary. Something like this: > > http://slackito.com/2011/08/24/separate-debug-information-with-gdb/ > > That leaves the main binary with a .gnu_debuglink section which points to the > debug information file name, and all the debug sections in the main elf file > have been stripped out. > > I'm looking at implementing support for this in ObjectFileELF, and I'm > thinking I can have the ObjectFileELF contain a pointer to another > ObjectFileELF object when we find a .gnu_debuglink. The debug sections in > that second ObjectFileELF can be added as child sections to the > .gnu_debuglink section in the main binary. > > I also need to get a list of paths to search for these debug files passed > down to ObjectFileELF. In gdb, this is the "set debug-file-directory" > command. That is all described here: > > http://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html > > Anyone have any comments / suggestions / gotchas on this before I start > heading down this path? Am I using the children section consistently with > what's expected? Any better ways to accomplish this? Yes: Checkout the SymbolVendor class. On MacOSX we store our debug info a separate file as well which is a dSYM bundle that contains DWARF. The SymbolVendorMacOSX takes care of locating the dSYM file for a given binary. The SymbolVendor class is designed exactly for this purpose: locate and use one or more object files, other than the main object file, to give more complete debug info for a debug session. The symbol vendor may just use the Module's object file if there aren't any other files with debug info. So in this case, you don't actually touch the ObjectFileELF plug-in at all besides possibly adding an abstract accessor to get the symbol file path(s). I believe there are probably many object file formats out there that have similar things (COFF has the same kind of thing), so we should add a "virtual FileSpecList ObjectFile::GetDebugSymbolFilePaths()" function to the main ObjectFile interface. lldb_private::Module has two accessors: GetObjectFile() and GetSymbolVendor(). The symbol vendor currently can either use the same object file that the module uses, or it can use a different file (the extra separate ELF file in your case). If the separate debug info is Linux only, I would make a SymbolVendorLinux, or if the separate debug info is for any ELF file, then make a SymbolVendorELF. The symbol vendor then can use any tricks up its sleeves to locate the given debug info file given the actual executable object file. On MacOSX, we have a UUID in each binary that is also contained in the dSYM file. The SymbolVendorMacOSX looks right next to the binary, it uses spotlight and many other tricks to locate the debug info file using the UUID. I believe you recently added support for the 20 byte UUID values to linux, so maybe this can be used in case you move your binary to another machine at a different path so you can still be able to locate your symbol files. So you will make one or two instances or ObjectFileELF now. In the case where the ELF executable file contains the debug info, you make on ObjectFileELF instance when making the module, then the SymbolVendorELF will check if there is a .gnu_debuglink section, and in this case there isn't one, so it will use the same ObjectFileELF (by getting a shared pointer to the object file form the module) and use this as the object file for the debug symbols. In the case where the ELF executable file doesn't contain the debug info, you make on ObjectFileELF instance when making the module, then the SymbolVendorELF will check if there is a .gnu_debuglink section, and in this case there _is_ one, so the SymbolVendorELF will make another instance of ObjectFileELF and use this as the object file for the debug symbols. The only tricky thing you have to do is to have this second ObjectFileELF create section/offset addresses using the sections from the Module's object file. I am not sure what these debug info files look like, or if they both have the same section definitions. On MacOSX, we have a copy of all the section definitions in the dSYM file so any symbols in the extra debug info will get mapped back to the actual sections from the main executable very easily. The dSYM file has a symbol table, the symbol table has a section index, so if and when we make symbols in this extra debug symbols object file, we use the actual section de! finitions from the actual object file. So checkout the SymbolVendorMacOSX and let me know if you have any questions, but at least you have a fully working sample code to look at. Greg Clayton _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
