mirror of
https://github.com/bminor/binutils-gdb.git
synced 2025-12-28 10:00:51 +00:00
dc294be54c
This patch fixes gdb PR symtab/15597. The bug is that the .gnu_debugaltlink section includes the build-id of the alt file, but gdb does not use it. This patch fixes the problem by changing gdb to do what it ought to always have done: verify the build id of the file found using the filename in .gnu_debugaltlink; and if that does not match, try to find the correct debug file using the build-id and debug-file-directory. This patch touches BFD. Previously, gdb had its own code for parsing .gnu_debugaltlink; I changed it to use the BFD functions after those were introduced. However, the BFD functions are incorrect -- they assume that .gnu_debugaltlink is formatted like .gnu_debuglink. However, it it is not. Instead, it consists of a file name followed by the build-id -- no alignment, and the build-id is not a CRC. Fixing this properly is a bit of a pain. But, because separate_alt_debug_file_exists just has a FIXME for the build-id case, I did not fix it properly. Instead I introduced a hack. This leaves BFD working just as well as it did before my patch. I'm willing to do something better here but I could use some guidance as to what. It seems that the build-id code in BFD is largely punted on. FWIW gdb is the only user of bfd_get_alt_debug_link_info outside of BFD itself. I moved the build-id logic out of elfread.c and into a new file. This seemed cleanest to me. Writing a test case was a bit of a pain. I added a couple new features to the DWARF assembler to handle this. Built and regtested on x86-64 Fedora 18. * bfd-in2.h: Rebuild. * opncls.c (bfd_get_alt_debug_link_info): Add buildid_len parameter. Change type of buildid_out. Update. (get_alt_debug_link_info_shim): New function. (bfd_follow_gnu_debuglink): Use it. * Makefile.in (SFILES): Add build-id.c. (HFILES_NO_SRCDIR): Add build-id.h. * build-id.c: New file, largely from elfread.c. Modified most functions. * build-id.h: New file. * dwarf2read.c (dwarf2_get_dwz_file): Update for change to bfd_get_alt_debug_link_info. Verify dwz file's build-id. Search for dwz file using build-id. * elfread.c (build_id_bfd_get, build_id_verify) (build_id_to_debug_filename, find_separate_debug_file): Remove. * gdb.dwarf2/dwzbuildid.exp: New file. * lib/dwarf.exp (Dwarf::_section): Add "flags" and "type" parameters. (Dwarf::_defer_output): Change "section" parameter to "section_spec"; update. (Dwarf::gnu_debugaltlink, Dwarf::_note, Dwarf::build_id): New procs.
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.