binutils-gdb/gdb/build-id.c

206 lines
5.6 KiB
C
Raw Normal View History

fix PR symtab/15597 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.
2013-10-09 03:56:15 +08:00
/* build-id-related functions.
Copyright (C) 1991-2019 Free Software Foundation, Inc.
fix PR symtab/15597 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.
2013-10-09 03:56:15 +08:00
This file is part of GDB.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>. */
#include "defs.h"
#include "bfd.h"
#include "gdb_bfd.h"
#include "build-id.h"
Normalize includes to use common/ This changes all includes to use the form "common/filename.h" rather than just "filename.h". This was written by a script. gdb/ChangeLog 2019-01-25 Tom Tromey <tom@tromey.com> * xtensa-linux-nat.c: Fix common/ includes. * xml-support.h: Fix common/ includes. * xml-support.c: Fix common/ includes. * x86-linux-nat.c: Fix common/ includes. * windows-nat.c: Fix common/ includes. * varobj.h: Fix common/ includes. * varobj.c: Fix common/ includes. * value.c: Fix common/ includes. * valops.c: Fix common/ includes. * utils.c: Fix common/ includes. * unittests/xml-utils-selftests.c: Fix common/ includes. * unittests/utils-selftests.c: Fix common/ includes. * unittests/unpack-selftests.c: Fix common/ includes. * unittests/tracepoint-selftests.c: Fix common/ includes. * unittests/style-selftests.c: Fix common/ includes. * unittests/string_view-selftests.c: Fix common/ includes. * unittests/scoped_restore-selftests.c: Fix common/ includes. * unittests/scoped_mmap-selftests.c: Fix common/ includes. * unittests/scoped_fd-selftests.c: Fix common/ includes. * unittests/rsp-low-selftests.c: Fix common/ includes. * unittests/parse-connection-spec-selftests.c: Fix common/ includes. * unittests/optional-selftests.c: Fix common/ includes. * unittests/offset-type-selftests.c: Fix common/ includes. * unittests/observable-selftests.c: Fix common/ includes. * unittests/mkdir-recursive-selftests.c: Fix common/ includes. * unittests/memrange-selftests.c: Fix common/ includes. * unittests/memory-map-selftests.c: Fix common/ includes. * unittests/lookup_name_info-selftests.c: Fix common/ includes. * unittests/function-view-selftests.c: Fix common/ includes. * unittests/environ-selftests.c: Fix common/ includes. * unittests/copy_bitwise-selftests.c: Fix common/ includes. * unittests/common-utils-selftests.c: Fix common/ includes. * unittests/cli-utils-selftests.c: Fix common/ includes. * unittests/array-view-selftests.c: Fix common/ includes. * ui-file.c: Fix common/ includes. * tui/tui-io.c: Fix common/ includes. * tracepoint.h: Fix common/ includes. * tracepoint.c: Fix common/ includes. * tracefile-tfile.c: Fix common/ includes. * top.h: Fix common/ includes. * top.c: Fix common/ includes. * thread.c: Fix common/ includes. * target/waitstatus.h: Fix common/ includes. * target/waitstatus.c: Fix common/ includes. * target.h: Fix common/ includes. * target.c: Fix common/ includes. * target-memory.c: Fix common/ includes. * target-descriptions.c: Fix common/ includes. * symtab.h: Fix common/ includes. * symfile.c: Fix common/ includes. * stap-probe.c: Fix common/ includes. * spu-linux-nat.c: Fix common/ includes. * sparc-nat.c: Fix common/ includes. * source.c: Fix common/ includes. * solib.c: Fix common/ includes. * solib-target.c: Fix common/ includes. * ser-unix.c: Fix common/ includes. * ser-tcp.c: Fix common/ includes. * ser-pipe.c: Fix common/ includes. * ser-base.c: Fix common/ includes. * selftest-arch.c: Fix common/ includes. * s12z-tdep.c: Fix common/ includes. * rust-exp.y: Fix common/ includes. * rs6000-aix-tdep.c: Fix common/ includes. * riscv-tdep.c: Fix common/ includes. * remote.c: Fix common/ includes. * remote-notif.h: Fix common/ includes. * remote-fileio.h: Fix common/ includes. * remote-fileio.c: Fix common/ includes. * regcache.h: Fix common/ includes. * regcache.c: Fix common/ includes. * record-btrace.c: Fix common/ includes. * python/python.c: Fix common/ includes. * python/py-type.c: Fix common/ includes. * python/py-inferior.c: Fix common/ includes. * progspace.h: Fix common/ includes. * producer.c: Fix common/ includes. * procfs.c: Fix common/ includes. * proc-api.c: Fix common/ includes. * printcmd.c: Fix common/ includes. * ppc-linux-nat.c: Fix common/ includes. * parser-defs.h: Fix common/ includes. * osdata.c: Fix common/ includes. * obsd-nat.c: Fix common/ includes. * nat/x86-linux.c: Fix common/ includes. * nat/x86-linux-dregs.c: Fix common/ includes. * nat/x86-dregs.h: Fix common/ includes. * nat/x86-dregs.c: Fix common/ includes. * nat/ppc-linux.c: Fix common/ includes. * nat/mips-linux-watch.h: Fix common/ includes. * nat/mips-linux-watch.c: Fix common/ includes. * nat/linux-waitpid.c: Fix common/ includes. * nat/linux-ptrace.h: Fix common/ includes. * nat/linux-ptrace.c: Fix common/ includes. * nat/linux-procfs.c: Fix common/ includes. * nat/linux-personality.c: Fix common/ includes. * nat/linux-osdata.c: Fix common/ includes. * nat/linux-namespaces.c: Fix common/ includes. * nat/linux-btrace.h: Fix common/ includes. * nat/linux-btrace.c: Fix common/ includes. * nat/fork-inferior.c: Fix common/ includes. * nat/amd64-linux-siginfo.c: Fix common/ includes. * nat/aarch64-sve-linux-ptrace.c: Fix common/ includes. * nat/aarch64-linux.c: Fix common/ includes. * nat/aarch64-linux-hw-point.h: Fix common/ includes. * nat/aarch64-linux-hw-point.c: Fix common/ includes. * namespace.h: Fix common/ includes. * mips-linux-tdep.c: Fix common/ includes. * minsyms.c: Fix common/ includes. * mi/mi-parse.h: Fix common/ includes. * mi/mi-main.c: Fix common/ includes. * mi/mi-cmd-env.c: Fix common/ includes. * memrange.h: Fix common/ includes. * memattr.c: Fix common/ includes. * maint.h: Fix common/ includes. * maint.c: Fix common/ includes. * main.c: Fix common/ includes. * machoread.c: Fix common/ includes. * location.c: Fix common/ includes. * linux-thread-db.c: Fix common/ includes. * linux-nat.c: Fix common/ includes. * linux-fork.c: Fix common/ includes. * inline-frame.c: Fix common/ includes. * infrun.c: Fix common/ includes. * inflow.c: Fix common/ includes. * inferior.h: Fix common/ includes. * inferior.c: Fix common/ includes. * infcmd.c: Fix common/ includes. * inf-ptrace.c: Fix common/ includes. * inf-child.c: Fix common/ includes. * ia64-linux-nat.c: Fix common/ includes. * i387-tdep.c: Fix common/ includes. * i386-tdep.c: Fix common/ includes. * i386-linux-tdep.c: Fix common/ includes. * i386-linux-nat.c: Fix common/ includes. * i386-go32-tdep.c: Fix common/ includes. * i386-fbsd-tdep.c: Fix common/ includes. * i386-fbsd-nat.c: Fix common/ includes. * guile/scm-type.c: Fix common/ includes. * guile/guile.c: Fix common/ includes. * go32-nat.c: Fix common/ includes. * gnu-nat.c: Fix common/ includes. * gdbthread.h: Fix common/ includes. * gdbarch-selftests.c: Fix common/ includes. * gdb_usleep.c: Fix common/ includes. * gdb_select.h: Fix common/ includes. * gdb_bfd.c: Fix common/ includes. * gcore.c: Fix common/ includes. * fork-child.c: Fix common/ includes. * findvar.c: Fix common/ includes. * fbsd-nat.c: Fix common/ includes. * event-top.c: Fix common/ includes. * event-loop.c: Fix common/ includes. * dwarf2read.c: Fix common/ includes. * dwarf2loc.c: Fix common/ includes. * dwarf2-frame.c: Fix common/ includes. * dwarf-index-cache.c: Fix common/ includes. * dtrace-probe.c: Fix common/ includes. * disasm-selftests.c: Fix common/ includes. * defs.h: Fix common/ includes. * csky-tdep.c: Fix common/ includes. * cp-valprint.c: Fix common/ includes. * cp-support.h: Fix common/ includes. * cp-support.c: Fix common/ includes. * corelow.c: Fix common/ includes. * completer.h: Fix common/ includes. * completer.c: Fix common/ includes. * compile/compile.c: Fix common/ includes. * compile/compile-loc2c.c: Fix common/ includes. * compile/compile-cplus-types.c: Fix common/ includes. * compile/compile-cplus-symbols.c: Fix common/ includes. * command.h: Fix common/ includes. * cli/cli-dump.c: Fix common/ includes. * cli/cli-cmds.c: Fix common/ includes. * charset.c: Fix common/ includes. * build-id.c: Fix common/ includes. * btrace.h: Fix common/ includes. * btrace.c: Fix common/ includes. * breakpoint.h: Fix common/ includes. * breakpoint.c: Fix common/ includes. * ax.h: (enum agent_op): Fix common/ includes. * ax-general.c (struct aop_map): Fix common/ includes. * ax-gdb.c: Fix common/ includes. * auxv.c: Fix common/ includes. * auto-load.c: Fix common/ includes. * arm-tdep.c: Fix common/ includes. * arch/riscv.c: Fix common/ includes. * arch/ppc-linux-common.c: Fix common/ includes. * arch/i386.c: Fix common/ includes. * arch/arm.c: Fix common/ includes. * arch/arm-linux.c: Fix common/ includes. * arch/arm-get-next-pcs.c: Fix common/ includes. * arch/amd64.c: Fix common/ includes. * arch/aarch64.c: Fix common/ includes. * arch/aarch64-insn.c: Fix common/ includes. * arch-utils.c: Fix common/ includes. * amd64-windows-tdep.c: Fix common/ includes. * amd64-tdep.c: Fix common/ includes. * amd64-sol2-tdep.c: Fix common/ includes. * amd64-obsd-tdep.c: Fix common/ includes. * amd64-nbsd-tdep.c: Fix common/ includes. * amd64-linux-tdep.c: Fix common/ includes. * amd64-linux-nat.c: Fix common/ includes. * amd64-fbsd-tdep.c: Fix common/ includes. * amd64-fbsd-nat.c: Fix common/ includes. * amd64-dicos-tdep.c: Fix common/ includes. * amd64-darwin-tdep.c: Fix common/ includes. * agent.c: Fix common/ includes. * ada-lang.h: Fix common/ includes. * ada-lang.c: Fix common/ includes. * aarch64-tdep.c: Fix common/ includes. gdb/gdbserver/ChangeLog 2019-01-25 Tom Tromey <tom@tromey.com> * win32-low.c: Fix common/ includes. * win32-i386-low.c: Fix common/ includes. * tracepoint.c: Fix common/ includes. * thread-db.c: Fix common/ includes. * target.h: Fix common/ includes. * symbol.c: Fix common/ includes. * spu-low.c: Fix common/ includes. * server.h: Fix common/ includes. * server.c: Fix common/ includes. * remote-utils.c: Fix common/ includes. * regcache.h: Fix common/ includes. * regcache.c: Fix common/ includes. * nto-x86-low.c: Fix common/ includes. * notif.h: Fix common/ includes. * mem-break.h: Fix common/ includes. * lynx-low.c: Fix common/ includes. * lynx-i386-low.c: Fix common/ includes. * linux-x86-tdesc-selftest.c: Fix common/ includes. * linux-x86-low.c: Fix common/ includes. * linux-low.c: Fix common/ includes. * inferiors.h: Fix common/ includes. * i387-fp.c: Fix common/ includes. * hostio.c: Fix common/ includes. * hostio-errno.c: Fix common/ includes. * gdbthread.h: Fix common/ includes. * gdbreplay.c: Fix common/ includes. * fork-child.c: Fix common/ includes. * event-loop.c: Fix common/ includes. * ax.c: (enum gdb_agent_op): Fix common/ includes.
2019-01-24 01:21:39 +08:00
#include "common/gdb_vecs.h"
fix PR symtab/15597 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.
2013-10-09 03:56:15 +08:00
#include "symfile.h"
#include "objfiles.h"
#include "filenames.h"
Convert "remote:" sysroots to "target:" and remove "remote:" The functionality of "target:" sysroots is a superset of the functionality of "remote:" sysroots. This commit causes the "set sysroot" command to rewrite "remote:" sysroots as "target:" sysroots and replaces "remote:" specific code with "target:" specific code where still necessary. gdb/ChangeLog: * remote.h (REMOTE_SYSROOT_PREFIX): Remove definition. (remote_filename_p): Remove declaration. (remote_bfd_open): Likewise. * remote.c (remote_bfd_iovec_open): Remove function. (remote_bfd_iovec_close): Likewise. (remote_bfd_iovec_pread): Likewise. (remote_bfd_iovec_stat): Likewise. (remote_filename_p): Likewise. (remote_bfd_open): Likewise. * symfile.h (gdb_bfd_open_maybe_remote): Remove declaration. * symfile.c (separate_debug_file_exists): Use gdb_bfd_open. (gdb_bfd_open_maybe_remote): Remove function. (symfile_bfd_open): Replace remote filename check with target filename check. (reread_symbols): Use gdb_bfd_open. * build-id.c (gdbcore.h): New include. (build_id_to_debug_bfd): Use gdb_bfd_open. * infcmd.c (attach_command_post_wait): Remove remote filename check. * solib.c (solib_find): Replace remote-specific handling with target-specific handling. Update comments where necessary. (solib_bfd_open): Replace remote-specific handling with target-specific handling. (gdb_sysroot_changed): New function. (_initialize_solib): Call the above when gdb_sysroot changes. * windows-tdep.c (gdbcore.h): New include. (windows_xfer_shared_library): Use gdb_bfd_open.
2015-04-02 20:38:29 +08:00
#include "gdbcore.h"
fix PR symtab/15597 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.
2013-10-09 03:56:15 +08:00
/* See build-id.h. */
fix PR symtab/15597 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.
2013-10-09 03:56:15 +08:00
Allow gdb to find debug symbols file by build-id for PE file format also This promotes BFD's struct elf_build_id to the generic struct bfd_build_id, populated when an ELF or PE BFD is read. gdb is updated to use that, and to use the build-id to find symbols for PE files also. There is currently no generic way to extract the build-id from an object file, perhaps an option to objdump to do this might make sense? On x86_64-pc-cygwin, gdb's sepdebug.exp changes: -# of unsupported tests 1 +# of expected passes 90 I don't seem to get consistent testsuite runs on i686-linux-gnu, but there don't appear to be any regressions. bfd/ChangeLog: 2015-06-10 Jon Turney <jon.turney@dronecode.org.uk> * elf-bfd.h : Remove struct elf_build_id. * bfd.c : Add struct bfd_build_id. * bfd-in2.h: Regenerate. * elf.c (elfobj_grok_gnu_build_id): Update to use bfd_build_id. * libpei.h: Add protoype and macros for bfd_XXi_slurp_codeview_record. * peXXigen.c (_bfd_XXi_slurp_codeview_record): Make public * peicode.h (pe_bfd_read_buildid): Add. (pe_bfd_object_p): Use pe_bfd_read_buildid(). gdb/ChangeLog: 2015-06-10 Jon Turney <jon.turney@dronecode.org.uk> * build-id.c: Don't include elf-bfd.h. (build_id_bfd_get): Use bfd_build_id. (build_id_verify): Ditto. * build-id.h: Ditto. (find_separate_debug_file_by_buildid): Ditto. * python/py-objfile.c: Don't include elf-bfd.h. (objfpy_get_build_id) Use bfd_build_id. (objfpy_build_id_matches, objfpy_lookup_objfile_by_build_id): Ditto. * coffread.c: Include build-id.h. (coff_symfile_read): Try find_separate_debug_file_by_buildid. gdb/doc/ChangeLog: 2015-06-10 Jon Turney <jon.turney@dronecode.org.uk> * gdb.texinfo (Separate Debug Files): Document that PE is also supported. gdb/testsuite/ChangeLog: 2015-06-10 Jon Turney <jon.turney@dronecode.org.uk> * gdb.base/sepdebug.exp: Add EXEEXT where needed. * lib/gdb.exp (get_build_id): Teach how to extract build-id from a PE file. * lib/future.exp (gdb_find_objdump): Add gdb_find_objdump. Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
2015-04-08 03:49:08 +08:00
const struct bfd_build_id *
fix PR symtab/15597 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.
2013-10-09 03:56:15 +08:00
build_id_bfd_get (bfd *abfd)
{
Allow gdb to find debug symbols file by build-id for PE file format also This promotes BFD's struct elf_build_id to the generic struct bfd_build_id, populated when an ELF or PE BFD is read. gdb is updated to use that, and to use the build-id to find symbols for PE files also. There is currently no generic way to extract the build-id from an object file, perhaps an option to objdump to do this might make sense? On x86_64-pc-cygwin, gdb's sepdebug.exp changes: -# of unsupported tests 1 +# of expected passes 90 I don't seem to get consistent testsuite runs on i686-linux-gnu, but there don't appear to be any regressions. bfd/ChangeLog: 2015-06-10 Jon Turney <jon.turney@dronecode.org.uk> * elf-bfd.h : Remove struct elf_build_id. * bfd.c : Add struct bfd_build_id. * bfd-in2.h: Regenerate. * elf.c (elfobj_grok_gnu_build_id): Update to use bfd_build_id. * libpei.h: Add protoype and macros for bfd_XXi_slurp_codeview_record. * peXXigen.c (_bfd_XXi_slurp_codeview_record): Make public * peicode.h (pe_bfd_read_buildid): Add. (pe_bfd_object_p): Use pe_bfd_read_buildid(). gdb/ChangeLog: 2015-06-10 Jon Turney <jon.turney@dronecode.org.uk> * build-id.c: Don't include elf-bfd.h. (build_id_bfd_get): Use bfd_build_id. (build_id_verify): Ditto. * build-id.h: Ditto. (find_separate_debug_file_by_buildid): Ditto. * python/py-objfile.c: Don't include elf-bfd.h. (objfpy_get_build_id) Use bfd_build_id. (objfpy_build_id_matches, objfpy_lookup_objfile_by_build_id): Ditto. * coffread.c: Include build-id.h. (coff_symfile_read): Try find_separate_debug_file_by_buildid. gdb/doc/ChangeLog: 2015-06-10 Jon Turney <jon.turney@dronecode.org.uk> * gdb.texinfo (Separate Debug Files): Document that PE is also supported. gdb/testsuite/ChangeLog: 2015-06-10 Jon Turney <jon.turney@dronecode.org.uk> * gdb.base/sepdebug.exp: Add EXEEXT where needed. * lib/gdb.exp (get_build_id): Teach how to extract build-id from a PE file. * lib/future.exp (gdb_find_objdump): Add gdb_find_objdump. Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
2015-04-08 03:49:08 +08:00
if (!bfd_check_format (abfd, bfd_object))
fix PR symtab/15597 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.
2013-10-09 03:56:15 +08:00
return NULL;
Allow gdb to find debug symbols file by build-id for PE file format also This promotes BFD's struct elf_build_id to the generic struct bfd_build_id, populated when an ELF or PE BFD is read. gdb is updated to use that, and to use the build-id to find symbols for PE files also. There is currently no generic way to extract the build-id from an object file, perhaps an option to objdump to do this might make sense? On x86_64-pc-cygwin, gdb's sepdebug.exp changes: -# of unsupported tests 1 +# of expected passes 90 I don't seem to get consistent testsuite runs on i686-linux-gnu, but there don't appear to be any regressions. bfd/ChangeLog: 2015-06-10 Jon Turney <jon.turney@dronecode.org.uk> * elf-bfd.h : Remove struct elf_build_id. * bfd.c : Add struct bfd_build_id. * bfd-in2.h: Regenerate. * elf.c (elfobj_grok_gnu_build_id): Update to use bfd_build_id. * libpei.h: Add protoype and macros for bfd_XXi_slurp_codeview_record. * peXXigen.c (_bfd_XXi_slurp_codeview_record): Make public * peicode.h (pe_bfd_read_buildid): Add. (pe_bfd_object_p): Use pe_bfd_read_buildid(). gdb/ChangeLog: 2015-06-10 Jon Turney <jon.turney@dronecode.org.uk> * build-id.c: Don't include elf-bfd.h. (build_id_bfd_get): Use bfd_build_id. (build_id_verify): Ditto. * build-id.h: Ditto. (find_separate_debug_file_by_buildid): Ditto. * python/py-objfile.c: Don't include elf-bfd.h. (objfpy_get_build_id) Use bfd_build_id. (objfpy_build_id_matches, objfpy_lookup_objfile_by_build_id): Ditto. * coffread.c: Include build-id.h. (coff_symfile_read): Try find_separate_debug_file_by_buildid. gdb/doc/ChangeLog: 2015-06-10 Jon Turney <jon.turney@dronecode.org.uk> * gdb.texinfo (Separate Debug Files): Document that PE is also supported. gdb/testsuite/ChangeLog: 2015-06-10 Jon Turney <jon.turney@dronecode.org.uk> * gdb.base/sepdebug.exp: Add EXEEXT where needed. * lib/gdb.exp (get_build_id): Teach how to extract build-id from a PE file. * lib/future.exp (gdb_find_objdump): Add gdb_find_objdump. Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
2015-04-08 03:49:08 +08:00
if (abfd->build_id != NULL)
return abfd->build_id;
/* No build-id */
return NULL;
fix PR symtab/15597 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.
2013-10-09 03:56:15 +08:00
}
/* See build-id.h. */
int
build_id_verify (bfd *abfd, size_t check_len, const bfd_byte *check)
{
Allow gdb to find debug symbols file by build-id for PE file format also This promotes BFD's struct elf_build_id to the generic struct bfd_build_id, populated when an ELF or PE BFD is read. gdb is updated to use that, and to use the build-id to find symbols for PE files also. There is currently no generic way to extract the build-id from an object file, perhaps an option to objdump to do this might make sense? On x86_64-pc-cygwin, gdb's sepdebug.exp changes: -# of unsupported tests 1 +# of expected passes 90 I don't seem to get consistent testsuite runs on i686-linux-gnu, but there don't appear to be any regressions. bfd/ChangeLog: 2015-06-10 Jon Turney <jon.turney@dronecode.org.uk> * elf-bfd.h : Remove struct elf_build_id. * bfd.c : Add struct bfd_build_id. * bfd-in2.h: Regenerate. * elf.c (elfobj_grok_gnu_build_id): Update to use bfd_build_id. * libpei.h: Add protoype and macros for bfd_XXi_slurp_codeview_record. * peXXigen.c (_bfd_XXi_slurp_codeview_record): Make public * peicode.h (pe_bfd_read_buildid): Add. (pe_bfd_object_p): Use pe_bfd_read_buildid(). gdb/ChangeLog: 2015-06-10 Jon Turney <jon.turney@dronecode.org.uk> * build-id.c: Don't include elf-bfd.h. (build_id_bfd_get): Use bfd_build_id. (build_id_verify): Ditto. * build-id.h: Ditto. (find_separate_debug_file_by_buildid): Ditto. * python/py-objfile.c: Don't include elf-bfd.h. (objfpy_get_build_id) Use bfd_build_id. (objfpy_build_id_matches, objfpy_lookup_objfile_by_build_id): Ditto. * coffread.c: Include build-id.h. (coff_symfile_read): Try find_separate_debug_file_by_buildid. gdb/doc/ChangeLog: 2015-06-10 Jon Turney <jon.turney@dronecode.org.uk> * gdb.texinfo (Separate Debug Files): Document that PE is also supported. gdb/testsuite/ChangeLog: 2015-06-10 Jon Turney <jon.turney@dronecode.org.uk> * gdb.base/sepdebug.exp: Add EXEEXT where needed. * lib/gdb.exp (get_build_id): Teach how to extract build-id from a PE file. * lib/future.exp (gdb_find_objdump): Add gdb_find_objdump. Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
2015-04-08 03:49:08 +08:00
const struct bfd_build_id *found;
fix PR symtab/15597 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.
2013-10-09 03:56:15 +08:00
int retval = 0;
found = build_id_bfd_get (abfd);
if (found == NULL)
warning (_("File \"%s\" has no build-id, file skipped"),
bfd_get_filename (abfd));
else if (found->size != check_len
|| memcmp (found->data, check, found->size) != 0)
warning (_("File \"%s\" has a different build-id, file skipped"),
bfd_get_filename (abfd));
else
retval = 1;
return retval;
}
Look for build-id-based separate debug files under the sysroot When looking for a separate debug file that matches a given build-id, GDB only looks in the host's debug dir (typically /usr/lib/debug). This patch makes it look in the sysroot as well. This is to match the behavior of GDB when using debuglink-based separate debug files, introduced in : 402d2bfec42 ("Look for separate debug files in debug directories under a sysroot.") In the following example, my sysroot is "/tmp/sysroot" and I am trying to load symbols for /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so. This is the current behavior: (gdb) file /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so Reading symbols from /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so... Looking for separate debug info (build-id) for /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so Trying /usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... no, unable to compute real path <snip> (No debugging symbols found in /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so) With this patch: (gdb) file /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so Reading symbols from /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so... Looking for separate debug info (build-id) for /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so Trying /usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... no, unable to compute real path Trying /tmp/sysroot/usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... yes! Reading symbols from /tmp/sysroot/usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... In the original code, there is a suspicious "abfd.release ()" in build_id_to_debug_bfd, that I don't understand. If a file with the right name exists but its build-id note doesn't match, we release (leak) our reference, meaning the file will stay open? I removed it in the new code, so that the reference is dropped if we end up not using that file. I tested briefly by corrupting a separate debug file to trigger this code, nothing exploded. gdb/ChangeLog: * build-id.c (build_id_to_debug_bfd_1): New function. (build_id_to_debug_bfd): Look for separate debug file in sysroot.
2019-02-23 04:09:23 +08:00
/* Helper for build_id_to_debug_bfd. LINK is a path to a potential
build-id-based separate debug file, potentially a symlink to the real file.
If the file exists and matches BUILD_ID, return a BFD reference to it. */
static gdb_bfd_ref_ptr
build_id_to_debug_bfd_1 (const std::string &link, size_t build_id_len,
const bfd_byte *build_id)
{
if (separate_debug_file_debug)
{
printf_unfiltered (_(" Trying %s..."), link.c_str ());
gdb_flush (gdb_stdout);
}
/* lrealpath() is expensive even for the usually non-existent files. */
gdb::unique_xmalloc_ptr<char> filename;
if (access (link.c_str (), F_OK) == 0)
filename.reset (lrealpath (link.c_str ()));
if (filename == NULL)
{
if (separate_debug_file_debug)
printf_unfiltered (_(" no, unable to compute real path\n"));
return {};
}
/* We expect to be silent on the non-existing files. */
gdb_bfd_ref_ptr debug_bfd = gdb_bfd_open (filename.get (), gnutarget, -1);
if (debug_bfd == NULL)
{
if (separate_debug_file_debug)
printf_unfiltered (_(" no, unable to open.\n"));
return {};
}
if (!build_id_verify (debug_bfd.get(), build_id_len, build_id))
{
if (separate_debug_file_debug)
printf_unfiltered (_(" no, build-id does not match.\n"));
return {};
}
if (separate_debug_file_debug)
printf_unfiltered (_(" yes!\n"));
return debug_bfd;
}
fix PR symtab/15597 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.
2013-10-09 03:56:15 +08:00
/* See build-id.h. */
Use class to manage BFD reference counts This introduces a new specialization of gdb::ref_ptr that can be used to manage BFD reference counts. Then it changes most places in gdb to use this new class, rather than explicit reference-counting or cleanups. This patch removes make_cleanup_bfd_unref. If you look you will see a couple of spots using "release" where a use of gdb_bfd_ref_ptr would be cleaner. These will be fixed in the next patch. I think this patch fixes some latent bugs. For example, it seems to me that previously objfpy_add_separate_debug_file leaked a BFD. I'm not 100% certain that the macho_symfile_read_all_oso change is correct. The existing code here is hard for me to follow. One goal of this sort of automated reference counting, though, is to make it more difficult to make logic errors; so hopefully the code is clear now. 2017-01-10 Tom Tromey <tom@tromey.com> * windows-tdep.c (windows_xfer_shared_library): Update. * windows-nat.c (windows_make_so): Update. * utils.h (make_cleanup_bfd_unref): Remove. * utils.c (do_bfd_close_cleanup, make_cleanup_bfd_unref): Remove. * symfile.h (symfile_bfd_open) (find_separate_debug_file_in_section): Return gdb_bfd_ref_ptr. * symfile.c (read_symbols, symbol_file_add) (separate_debug_file_exists): Update. (symfile_bfd_open): Return gdb_bfd_ref_ptr. (generic_load, reread_symbols): Update. * symfile-mem.c (symbol_file_add_from_memory): Update. * spu-linux-nat.c (spu_bfd_open): Return gdb_bfd_ref_ptr. (spu_symbol_file_add_from_memory): Update. * solist.h (struct target_so_ops) <bfd_open>: Return gdb_bfd_ref_ptr. (solib_bfd_fopen, solib_bfd_open): Return gdb_bfd_ref_ptr. * solib.c (solib_bfd_fopen, solib_bfd_open): Return gdb_bfd_ref_ptr. (solib_map_sections, reload_shared_libraries_1): Update. * solib-svr4.c (enable_break): Update. * solib-spu.c (spu_bfd_fopen): Return gdb_bfd_ref_ptr. * solib-frv.c (enable_break2): Update. * solib-dsbt.c (enable_break): Update. * solib-darwin.c (gdb_bfd_mach_o_fat_extract): Return gdb_bfd_ref_ptr. (darwin_solib_get_all_image_info_addr_at_init): Update. (darwin_bfd_open): Return gdb_bfd_ref_ptr. * solib-aix.c (solib_aix_bfd_open): Return gdb_bfd_ref_ptr. * record-full.c (record_full_save): Update. * python/py-objfile.c (objfpy_add_separate_debug_file): Update. * procfs.c (insert_dbx_link_bpt_in_file): Update. * minidebug.c (find_separate_debug_file_in_section): Return gdb_bfd_ref_ptr. * machoread.c (macho_add_oso_symfile): Change abfd to gdb_bfd_ref_ptr. (macho_symfile_read_all_oso): Update. (macho_check_dsym): Return gdb_bfd_ref_ptr. (macho_symfile_read): Update. * jit.c (bfd_open_from_target_memory): Return gdb_bfd_ref_ptr. (jit_bfd_try_read_symtab): Update. * gdb_bfd.h (gdb_bfd_open, gdb_bfd_fopen, gdb_bfd_openr) (gdb_bfd_openw, gdb_bfd_openr_iovec) (gdb_bfd_openr_next_archived_file, gdb_bfd_fdopenr): Return gdb_bfd_ref_ptr. (gdb_bfd_ref_policy): New struct. (gdb_bfd_ref_ptr): New typedef. * gdb_bfd.c (gdb_bfd_open, gdb_bfd_fopen, gdb_bfd_openr) (gdb_bfd_openw, gdb_bfd_openr_iovec) (gdb_bfd_openr_next_archived_file, gdb_bfd_fdopenr): Return gdb_bfd_ref_ptr. * gcore.h (create_gcore_bfd): Return gdb_bfd_ref_ptr. * gcore.c (create_gcore_bfd): Return gdb_bfd_ref_ptr. (gcore_command): Update. * exec.c (exec_file_attach): Update. * elfread.c (elf_symfile_read): Update. * dwarf2read.c (dwarf2_get_dwz_file): Update. (try_open_dwop_file, open_dwo_file): Return gdb_bfd_ref_ptr. (open_and_init_dwo_file): Update. (open_dwp_file): Return gdb_bfd_ref_ptr. (open_and_init_dwp_file): Update. * corelow.c (core_open): Update. * compile/compile-object-load.c (compile_object_load): Update. * common/gdb_ref_ptr.h (ref_ptr::operator->): New operator. * coffread.c (coff_symfile_read): Update. * cli/cli-dump.c (bfd_openr_or_error, bfd_openw_or_error): Return gdb_bfd_ref_ptr. Rename. (dump_bfd_file, restore_command): Update. * build-id.h (build_id_to_debug_bfd): Return gdb_bfd_ref_ptr. * build-id.c (build_id_to_debug_bfd): Return gdb_bfd_ref_ptr. (find_separate_debug_file_by_buildid): Update.
2016-11-22 02:12:23 +08:00
gdb_bfd_ref_ptr
fix PR symtab/15597 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.
2013-10-09 03:56:15 +08:00
build_id_to_debug_bfd (size_t build_id_len, const bfd_byte *build_id)
{
/* Keep backward compatibility so that DEBUG_FILE_DIRECTORY being "" will
cause "/.build-id/..." lookups. */
Make delim_string_to_char_ptr_vec return an std::vector This patch makes delim_string_to_char_ptr_vec and all related functions use std::vector of gdb::unique_xmalloc_ptr. This allows getting rid of make_cleanup_free_char_ptr_vec. Returning a vector of unique_xmalloc_ptr instead of std::string allows to minimize the impacts on the calling code. We can evaluate later whether we could/should return a vector of std::strings instead. gdb/ChangeLog: * common/gdb_vecs.h (make_cleanup_free_char_ptr_vec): Remove. (delim_string_to_char_ptr_vec): Return std::vector of gdb::unique_xmalloc_ptr. (dirnames_to_char_ptr_vec_append): Take std::vector of gdb::unique_xmalloc_ptr. (dirnames_to_char_ptr_vec): Return std::vector of gdb::unique_xmalloc_ptr. * common/gdb_vecs.c (delim_string_to_char_ptr_vec_append): Take std::vector of gdb::unique_xmalloc_ptr, adjust the code. (delim_string_to_char_ptr_vec): Return an std::vector of gdb::unique_xmalloc_ptr, adjust the code. (dirnames_to_char_ptr_vec_append): Take an std::vector of gdb::unique_xmalloc_ptr, adjust the code. (dirnames_to_char_ptr_vec): Return an std::vector of gdb::unique_xmalloc_ptr, adjust the code. * auto-load.c (auto_load_safe_path_vec): Change type to std::vector of gdb::unique_xmalloc_ptr. (auto_load_expand_dir_vars): Return an std::vector of gdb::unique_xmalloc_ptr, adjust the code. (auto_load_safe_path_vec_update): Adjust. (filename_is_in_auto_load_safe_path_vec): Adjust. (auto_load_objfile_script_1): Adjust. * build-id.c (build_id_to_debug_bfd): Adjust. * linux-thread-db.c (thread_db_load_search): Adjust. * source.c (add_path): Adjust. (openp): Adjust. * symfile.c (find_separate_debug_file): Adjust. * utils.c (do_free_char_ptr_vec): Remove. (make_cleanup_free_char_ptr_vec): Remove. gdb/gdbserver/ChangeLog: * server.c (parse_debug_format_options): Adjust to delim_string_to_char_ptr_vec changes. * thread-db.c (thread_db_load_search): Adjust to dirnames_to_char_ptr_vec changes.
2018-03-03 12:22:06 +08:00
std::vector<gdb::unique_xmalloc_ptr<char>> debugdir_vec
= dirnames_to_char_ptr_vec (debug_file_directory);
fix PR symtab/15597 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.
2013-10-09 03:56:15 +08:00
Make delim_string_to_char_ptr_vec return an std::vector This patch makes delim_string_to_char_ptr_vec and all related functions use std::vector of gdb::unique_xmalloc_ptr. This allows getting rid of make_cleanup_free_char_ptr_vec. Returning a vector of unique_xmalloc_ptr instead of std::string allows to minimize the impacts on the calling code. We can evaluate later whether we could/should return a vector of std::strings instead. gdb/ChangeLog: * common/gdb_vecs.h (make_cleanup_free_char_ptr_vec): Remove. (delim_string_to_char_ptr_vec): Return std::vector of gdb::unique_xmalloc_ptr. (dirnames_to_char_ptr_vec_append): Take std::vector of gdb::unique_xmalloc_ptr. (dirnames_to_char_ptr_vec): Return std::vector of gdb::unique_xmalloc_ptr. * common/gdb_vecs.c (delim_string_to_char_ptr_vec_append): Take std::vector of gdb::unique_xmalloc_ptr, adjust the code. (delim_string_to_char_ptr_vec): Return an std::vector of gdb::unique_xmalloc_ptr, adjust the code. (dirnames_to_char_ptr_vec_append): Take an std::vector of gdb::unique_xmalloc_ptr, adjust the code. (dirnames_to_char_ptr_vec): Return an std::vector of gdb::unique_xmalloc_ptr, adjust the code. * auto-load.c (auto_load_safe_path_vec): Change type to std::vector of gdb::unique_xmalloc_ptr. (auto_load_expand_dir_vars): Return an std::vector of gdb::unique_xmalloc_ptr, adjust the code. (auto_load_safe_path_vec_update): Adjust. (filename_is_in_auto_load_safe_path_vec): Adjust. (auto_load_objfile_script_1): Adjust. * build-id.c (build_id_to_debug_bfd): Adjust. * linux-thread-db.c (thread_db_load_search): Adjust. * source.c (add_path): Adjust. (openp): Adjust. * symfile.c (find_separate_debug_file): Adjust. * utils.c (do_free_char_ptr_vec): Remove. (make_cleanup_free_char_ptr_vec): Remove. gdb/gdbserver/ChangeLog: * server.c (parse_debug_format_options): Adjust to delim_string_to_char_ptr_vec changes. * thread-db.c (thread_db_load_search): Adjust to dirnames_to_char_ptr_vec changes.
2018-03-03 12:22:06 +08:00
for (const gdb::unique_xmalloc_ptr<char> &debugdir : debugdir_vec)
fix PR symtab/15597 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.
2013-10-09 03:56:15 +08:00
{
const gdb_byte *data = build_id;
size_t size = build_id_len;
Look for build-id-based separate debug files under the sysroot When looking for a separate debug file that matches a given build-id, GDB only looks in the host's debug dir (typically /usr/lib/debug). This patch makes it look in the sysroot as well. This is to match the behavior of GDB when using debuglink-based separate debug files, introduced in : 402d2bfec42 ("Look for separate debug files in debug directories under a sysroot.") In the following example, my sysroot is "/tmp/sysroot" and I am trying to load symbols for /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so. This is the current behavior: (gdb) file /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so Reading symbols from /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so... Looking for separate debug info (build-id) for /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so Trying /usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... no, unable to compute real path <snip> (No debugging symbols found in /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so) With this patch: (gdb) file /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so Reading symbols from /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so... Looking for separate debug info (build-id) for /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so Trying /usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... no, unable to compute real path Trying /tmp/sysroot/usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... yes! Reading symbols from /tmp/sysroot/usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... In the original code, there is a suspicious "abfd.release ()" in build_id_to_debug_bfd, that I don't understand. If a file with the right name exists but its build-id note doesn't match, we release (leak) our reference, meaning the file will stay open? I removed it in the new code, so that the reference is dropped if we end up not using that file. I tested briefly by corrupting a separate debug file to trigger this code, nothing exploded. gdb/ChangeLog: * build-id.c (build_id_to_debug_bfd_1): New function. (build_id_to_debug_bfd): Look for separate debug file in sysroot.
2019-02-23 04:09:23 +08:00
/* Compute where the file named after the build-id would be.
If debugdir is "/usr/lib/debug" and the build-id is abcdef, this will
give "/usr/lib/debug/.build-id/ab/cdef.debug". */
std::string link = debugdir.get ();
link += "/.build-id/";
fix PR symtab/15597 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.
2013-10-09 03:56:15 +08:00
if (size > 0)
{
size--;
string_appendf (link, "%02x/", (unsigned) *data++);
fix PR symtab/15597 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.
2013-10-09 03:56:15 +08:00
}
fix PR symtab/15597 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.
2013-10-09 03:56:15 +08:00
while (size-- > 0)
string_appendf (link, "%02x", (unsigned) *data++);
link += ".debug";
fix PR symtab/15597 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.
2013-10-09 03:56:15 +08:00
Look for build-id-based separate debug files under the sysroot When looking for a separate debug file that matches a given build-id, GDB only looks in the host's debug dir (typically /usr/lib/debug). This patch makes it look in the sysroot as well. This is to match the behavior of GDB when using debuglink-based separate debug files, introduced in : 402d2bfec42 ("Look for separate debug files in debug directories under a sysroot.") In the following example, my sysroot is "/tmp/sysroot" and I am trying to load symbols for /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so. This is the current behavior: (gdb) file /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so Reading symbols from /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so... Looking for separate debug info (build-id) for /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so Trying /usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... no, unable to compute real path <snip> (No debugging symbols found in /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so) With this patch: (gdb) file /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so Reading symbols from /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so... Looking for separate debug info (build-id) for /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so Trying /usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... no, unable to compute real path Trying /tmp/sysroot/usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... yes! Reading symbols from /tmp/sysroot/usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... In the original code, there is a suspicious "abfd.release ()" in build_id_to_debug_bfd, that I don't understand. If a file with the right name exists but its build-id note doesn't match, we release (leak) our reference, meaning the file will stay open? I removed it in the new code, so that the reference is dropped if we end up not using that file. I tested briefly by corrupting a separate debug file to trigger this code, nothing exploded. gdb/ChangeLog: * build-id.c (build_id_to_debug_bfd_1): New function. (build_id_to_debug_bfd): Look for separate debug file in sysroot.
2019-02-23 04:09:23 +08:00
gdb_bfd_ref_ptr debug_bfd
= build_id_to_debug_bfd_1 (link, build_id_len, build_id);
if (debug_bfd != NULL)
return debug_bfd;
Introduce "set debug separate-debug-file" I helped someone figure out why their separate debug info (debug link-based) was not found by gdb. It turns out that the debug file was not named properly. It made me realize that it is quite difficult to diagnose this kind of problems. This patch adds some debug output to show where GDB looks for those files, so that it should be (more) obvious to find what's wrong. Here's an example of the result, first with an example of unsuccessful lookup, and then a successful one. (gdb) set debug separate-debug-file on (gdb) file /usr/bin/gnome-calculator Reading symbols from /usr/bin/gnome-calculator... Looking for separate debug info (build-id) for /usr/bin/gnome-calculator Trying /usr/local/lib/debug/.build-id/0d/5c5e8c86dbe4f4f95f7a13de04f91d377f3c6a.debug Looking for separate debug info (debug link) for /usr/bin/gnome-calculator Trying /usr/bin/5c5e8c86dbe4f4f95f7a13de04f91d377f3c6a.debug Trying /usr/bin/.debug/5c5e8c86dbe4f4f95f7a13de04f91d377f3c6a.debug Trying /usr/local/lib/debug//usr/bin/5c5e8c86dbe4f4f95f7a13de04f91d377f3c6a.debug (no debugging symbols found)...done. (gdb) set debug-file-directory /usr/lib/debug (gdb) file /usr/bin/gnome-calculator Reading symbols from /usr/bin/gnome-calculator... Looking for separate debug info by build-id for /usr/bin/gnome-calculator Trying /usr/lib/debug/.build-id/0d/5c5e8c86dbe4f4f95f7a13de04f91d377f3c6a.debug Reading symbols from /usr/lib/debug/.build-id/0d/5c5e8c86dbe4f4f95f7a13de04f91d377f3c6a.debug...done. done. Note: here, the debug link happens to be named like the build-id, but it doesn't have to be this way. It puzzled me for a minute. gdb/ChangeLog: * NEWS (Changes since GDB 8.0): Announce {set,show} debug separate-debug-file commands. * symfile.h (separate_debug_file_debug): New global. * symfile.c (separate_debug_file_debug): New global. (separate_debug_file_exists, find_separate_debug_file): Add debug output. (_initialize_symfile): Add "set debug separate-debug-file" command. * build-id.c (build_id_to_debug_bfd, find_separate_debug_file_by_buildid): Add debug output. gdb/doc/ChangeLog: * gdb.texinfo (Optional Messages about Internal Happenings): Document {set,show} debug separate-debug-file commands.
2017-06-12 05:16:01 +08:00
Look for build-id-based separate debug files under the sysroot When looking for a separate debug file that matches a given build-id, GDB only looks in the host's debug dir (typically /usr/lib/debug). This patch makes it look in the sysroot as well. This is to match the behavior of GDB when using debuglink-based separate debug files, introduced in : 402d2bfec42 ("Look for separate debug files in debug directories under a sysroot.") In the following example, my sysroot is "/tmp/sysroot" and I am trying to load symbols for /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so. This is the current behavior: (gdb) file /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so Reading symbols from /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so... Looking for separate debug info (build-id) for /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so Trying /usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... no, unable to compute real path <snip> (No debugging symbols found in /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so) With this patch: (gdb) file /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so Reading symbols from /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so... Looking for separate debug info (build-id) for /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so Trying /usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... no, unable to compute real path Trying /tmp/sysroot/usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... yes! Reading symbols from /tmp/sysroot/usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... In the original code, there is a suspicious "abfd.release ()" in build_id_to_debug_bfd, that I don't understand. If a file with the right name exists but its build-id note doesn't match, we release (leak) our reference, meaning the file will stay open? I removed it in the new code, so that the reference is dropped if we end up not using that file. I tested briefly by corrupting a separate debug file to trigger this code, nothing exploded. gdb/ChangeLog: * build-id.c (build_id_to_debug_bfd_1): New function. (build_id_to_debug_bfd): Look for separate debug file in sysroot.
2019-02-23 04:09:23 +08:00
/* Try to look under the sysroot as well. If the sysroot is
"/the/sysroot", it will give
"/the/sysroot/usr/lib/debug/.build-id/ab/cdef.debug".
fix PR symtab/15597 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.
2013-10-09 03:56:15 +08:00
Look for build-id-based separate debug files under the sysroot When looking for a separate debug file that matches a given build-id, GDB only looks in the host's debug dir (typically /usr/lib/debug). This patch makes it look in the sysroot as well. This is to match the behavior of GDB when using debuglink-based separate debug files, introduced in : 402d2bfec42 ("Look for separate debug files in debug directories under a sysroot.") In the following example, my sysroot is "/tmp/sysroot" and I am trying to load symbols for /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so. This is the current behavior: (gdb) file /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so Reading symbols from /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so... Looking for separate debug info (build-id) for /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so Trying /usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... no, unable to compute real path <snip> (No debugging symbols found in /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so) With this patch: (gdb) file /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so Reading symbols from /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so... Looking for separate debug info (build-id) for /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so Trying /usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... no, unable to compute real path Trying /tmp/sysroot/usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... yes! Reading symbols from /tmp/sysroot/usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... In the original code, there is a suspicious "abfd.release ()" in build_id_to_debug_bfd, that I don't understand. If a file with the right name exists but its build-id note doesn't match, we release (leak) our reference, meaning the file will stay open? I removed it in the new code, so that the reference is dropped if we end up not using that file. I tested briefly by corrupting a separate debug file to trigger this code, nothing exploded. gdb/ChangeLog: * build-id.c (build_id_to_debug_bfd_1): New function. (build_id_to_debug_bfd): Look for separate debug file in sysroot.
2019-02-23 04:09:23 +08:00
Don't do it if the sysroot is the target system ("target:"). It
could work in theory, but the lrealpath in build_id_to_debug_bfd_1
only works with local paths. */
if (strcmp (gdb_sysroot, TARGET_SYSROOT_PREFIX) != 0)
{
Look for build-id-based separate debug files under the sysroot When looking for a separate debug file that matches a given build-id, GDB only looks in the host's debug dir (typically /usr/lib/debug). This patch makes it look in the sysroot as well. This is to match the behavior of GDB when using debuglink-based separate debug files, introduced in : 402d2bfec42 ("Look for separate debug files in debug directories under a sysroot.") In the following example, my sysroot is "/tmp/sysroot" and I am trying to load symbols for /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so. This is the current behavior: (gdb) file /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so Reading symbols from /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so... Looking for separate debug info (build-id) for /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so Trying /usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... no, unable to compute real path <snip> (No debugging symbols found in /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so) With this patch: (gdb) file /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so Reading symbols from /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so... Looking for separate debug info (build-id) for /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so Trying /usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... no, unable to compute real path Trying /tmp/sysroot/usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... yes! Reading symbols from /tmp/sysroot/usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... In the original code, there is a suspicious "abfd.release ()" in build_id_to_debug_bfd, that I don't understand. If a file with the right name exists but its build-id note doesn't match, we release (leak) our reference, meaning the file will stay open? I removed it in the new code, so that the reference is dropped if we end up not using that file. I tested briefly by corrupting a separate debug file to trigger this code, nothing exploded. gdb/ChangeLog: * build-id.c (build_id_to_debug_bfd_1): New function. (build_id_to_debug_bfd): Look for separate debug file in sysroot.
2019-02-23 04:09:23 +08:00
link = gdb_sysroot + link;
debug_bfd = build_id_to_debug_bfd_1 (link, build_id_len, build_id);
if (debug_bfd != NULL)
return debug_bfd;
}
fix PR symtab/15597 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.
2013-10-09 03:56:15 +08:00
}
Look for build-id-based separate debug files under the sysroot When looking for a separate debug file that matches a given build-id, GDB only looks in the host's debug dir (typically /usr/lib/debug). This patch makes it look in the sysroot as well. This is to match the behavior of GDB when using debuglink-based separate debug files, introduced in : 402d2bfec42 ("Look for separate debug files in debug directories under a sysroot.") In the following example, my sysroot is "/tmp/sysroot" and I am trying to load symbols for /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so. This is the current behavior: (gdb) file /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so Reading symbols from /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so... Looking for separate debug info (build-id) for /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so Trying /usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... no, unable to compute real path <snip> (No debugging symbols found in /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so) With this patch: (gdb) file /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so Reading symbols from /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so... Looking for separate debug info (build-id) for /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so Trying /usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... no, unable to compute real path Trying /tmp/sysroot/usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... yes! Reading symbols from /tmp/sysroot/usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... In the original code, there is a suspicious "abfd.release ()" in build_id_to_debug_bfd, that I don't understand. If a file with the right name exists but its build-id note doesn't match, we release (leak) our reference, meaning the file will stay open? I removed it in the new code, so that the reference is dropped if we end up not using that file. I tested briefly by corrupting a separate debug file to trigger this code, nothing exploded. gdb/ChangeLog: * build-id.c (build_id_to_debug_bfd_1): New function. (build_id_to_debug_bfd): Look for separate debug file in sysroot.
2019-02-23 04:09:23 +08:00
return {};
fix PR symtab/15597 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.
2013-10-09 03:56:15 +08:00
}
/* See build-id.h. */
std::string
fix PR symtab/15597 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.
2013-10-09 03:56:15 +08:00
find_separate_debug_file_by_buildid (struct objfile *objfile)
{
Allow gdb to find debug symbols file by build-id for PE file format also This promotes BFD's struct elf_build_id to the generic struct bfd_build_id, populated when an ELF or PE BFD is read. gdb is updated to use that, and to use the build-id to find symbols for PE files also. There is currently no generic way to extract the build-id from an object file, perhaps an option to objdump to do this might make sense? On x86_64-pc-cygwin, gdb's sepdebug.exp changes: -# of unsupported tests 1 +# of expected passes 90 I don't seem to get consistent testsuite runs on i686-linux-gnu, but there don't appear to be any regressions. bfd/ChangeLog: 2015-06-10 Jon Turney <jon.turney@dronecode.org.uk> * elf-bfd.h : Remove struct elf_build_id. * bfd.c : Add struct bfd_build_id. * bfd-in2.h: Regenerate. * elf.c (elfobj_grok_gnu_build_id): Update to use bfd_build_id. * libpei.h: Add protoype and macros for bfd_XXi_slurp_codeview_record. * peXXigen.c (_bfd_XXi_slurp_codeview_record): Make public * peicode.h (pe_bfd_read_buildid): Add. (pe_bfd_object_p): Use pe_bfd_read_buildid(). gdb/ChangeLog: 2015-06-10 Jon Turney <jon.turney@dronecode.org.uk> * build-id.c: Don't include elf-bfd.h. (build_id_bfd_get): Use bfd_build_id. (build_id_verify): Ditto. * build-id.h: Ditto. (find_separate_debug_file_by_buildid): Ditto. * python/py-objfile.c: Don't include elf-bfd.h. (objfpy_get_build_id) Use bfd_build_id. (objfpy_build_id_matches, objfpy_lookup_objfile_by_build_id): Ditto. * coffread.c: Include build-id.h. (coff_symfile_read): Try find_separate_debug_file_by_buildid. gdb/doc/ChangeLog: 2015-06-10 Jon Turney <jon.turney@dronecode.org.uk> * gdb.texinfo (Separate Debug Files): Document that PE is also supported. gdb/testsuite/ChangeLog: 2015-06-10 Jon Turney <jon.turney@dronecode.org.uk> * gdb.base/sepdebug.exp: Add EXEEXT where needed. * lib/gdb.exp (get_build_id): Teach how to extract build-id from a PE file. * lib/future.exp (gdb_find_objdump): Add gdb_find_objdump. Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
2015-04-08 03:49:08 +08:00
const struct bfd_build_id *build_id;
fix PR symtab/15597 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.
2013-10-09 03:56:15 +08:00
build_id = build_id_bfd_get (objfile->obfd);
if (build_id != NULL)
{
Introduce "set debug separate-debug-file" I helped someone figure out why their separate debug info (debug link-based) was not found by gdb. It turns out that the debug file was not named properly. It made me realize that it is quite difficult to diagnose this kind of problems. This patch adds some debug output to show where GDB looks for those files, so that it should be (more) obvious to find what's wrong. Here's an example of the result, first with an example of unsuccessful lookup, and then a successful one. (gdb) set debug separate-debug-file on (gdb) file /usr/bin/gnome-calculator Reading symbols from /usr/bin/gnome-calculator... Looking for separate debug info (build-id) for /usr/bin/gnome-calculator Trying /usr/local/lib/debug/.build-id/0d/5c5e8c86dbe4f4f95f7a13de04f91d377f3c6a.debug Looking for separate debug info (debug link) for /usr/bin/gnome-calculator Trying /usr/bin/5c5e8c86dbe4f4f95f7a13de04f91d377f3c6a.debug Trying /usr/bin/.debug/5c5e8c86dbe4f4f95f7a13de04f91d377f3c6a.debug Trying /usr/local/lib/debug//usr/bin/5c5e8c86dbe4f4f95f7a13de04f91d377f3c6a.debug (no debugging symbols found)...done. (gdb) set debug-file-directory /usr/lib/debug (gdb) file /usr/bin/gnome-calculator Reading symbols from /usr/bin/gnome-calculator... Looking for separate debug info by build-id for /usr/bin/gnome-calculator Trying /usr/lib/debug/.build-id/0d/5c5e8c86dbe4f4f95f7a13de04f91d377f3c6a.debug Reading symbols from /usr/lib/debug/.build-id/0d/5c5e8c86dbe4f4f95f7a13de04f91d377f3c6a.debug...done. done. Note: here, the debug link happens to be named like the build-id, but it doesn't have to be this way. It puzzled me for a minute. gdb/ChangeLog: * NEWS (Changes since GDB 8.0): Announce {set,show} debug separate-debug-file commands. * symfile.h (separate_debug_file_debug): New global. * symfile.c (separate_debug_file_debug): New global. (separate_debug_file_exists, find_separate_debug_file): Add debug output. (_initialize_symfile): Add "set debug separate-debug-file" command. * build-id.c (build_id_to_debug_bfd, find_separate_debug_file_by_buildid): Add debug output. gdb/doc/ChangeLog: * gdb.texinfo (Optional Messages about Internal Happenings): Document {set,show} debug separate-debug-file commands.
2017-06-12 05:16:01 +08:00
if (separate_debug_file_debug)
printf_unfiltered (_("\nLooking for separate debug info (build-id) for "
"%s\n"), objfile_name (objfile));
Use class to manage BFD reference counts This introduces a new specialization of gdb::ref_ptr that can be used to manage BFD reference counts. Then it changes most places in gdb to use this new class, rather than explicit reference-counting or cleanups. This patch removes make_cleanup_bfd_unref. If you look you will see a couple of spots using "release" where a use of gdb_bfd_ref_ptr would be cleaner. These will be fixed in the next patch. I think this patch fixes some latent bugs. For example, it seems to me that previously objfpy_add_separate_debug_file leaked a BFD. I'm not 100% certain that the macho_symfile_read_all_oso change is correct. The existing code here is hard for me to follow. One goal of this sort of automated reference counting, though, is to make it more difficult to make logic errors; so hopefully the code is clear now. 2017-01-10 Tom Tromey <tom@tromey.com> * windows-tdep.c (windows_xfer_shared_library): Update. * windows-nat.c (windows_make_so): Update. * utils.h (make_cleanup_bfd_unref): Remove. * utils.c (do_bfd_close_cleanup, make_cleanup_bfd_unref): Remove. * symfile.h (symfile_bfd_open) (find_separate_debug_file_in_section): Return gdb_bfd_ref_ptr. * symfile.c (read_symbols, symbol_file_add) (separate_debug_file_exists): Update. (symfile_bfd_open): Return gdb_bfd_ref_ptr. (generic_load, reread_symbols): Update. * symfile-mem.c (symbol_file_add_from_memory): Update. * spu-linux-nat.c (spu_bfd_open): Return gdb_bfd_ref_ptr. (spu_symbol_file_add_from_memory): Update. * solist.h (struct target_so_ops) <bfd_open>: Return gdb_bfd_ref_ptr. (solib_bfd_fopen, solib_bfd_open): Return gdb_bfd_ref_ptr. * solib.c (solib_bfd_fopen, solib_bfd_open): Return gdb_bfd_ref_ptr. (solib_map_sections, reload_shared_libraries_1): Update. * solib-svr4.c (enable_break): Update. * solib-spu.c (spu_bfd_fopen): Return gdb_bfd_ref_ptr. * solib-frv.c (enable_break2): Update. * solib-dsbt.c (enable_break): Update. * solib-darwin.c (gdb_bfd_mach_o_fat_extract): Return gdb_bfd_ref_ptr. (darwin_solib_get_all_image_info_addr_at_init): Update. (darwin_bfd_open): Return gdb_bfd_ref_ptr. * solib-aix.c (solib_aix_bfd_open): Return gdb_bfd_ref_ptr. * record-full.c (record_full_save): Update. * python/py-objfile.c (objfpy_add_separate_debug_file): Update. * procfs.c (insert_dbx_link_bpt_in_file): Update. * minidebug.c (find_separate_debug_file_in_section): Return gdb_bfd_ref_ptr. * machoread.c (macho_add_oso_symfile): Change abfd to gdb_bfd_ref_ptr. (macho_symfile_read_all_oso): Update. (macho_check_dsym): Return gdb_bfd_ref_ptr. (macho_symfile_read): Update. * jit.c (bfd_open_from_target_memory): Return gdb_bfd_ref_ptr. (jit_bfd_try_read_symtab): Update. * gdb_bfd.h (gdb_bfd_open, gdb_bfd_fopen, gdb_bfd_openr) (gdb_bfd_openw, gdb_bfd_openr_iovec) (gdb_bfd_openr_next_archived_file, gdb_bfd_fdopenr): Return gdb_bfd_ref_ptr. (gdb_bfd_ref_policy): New struct. (gdb_bfd_ref_ptr): New typedef. * gdb_bfd.c (gdb_bfd_open, gdb_bfd_fopen, gdb_bfd_openr) (gdb_bfd_openw, gdb_bfd_openr_iovec) (gdb_bfd_openr_next_archived_file, gdb_bfd_fdopenr): Return gdb_bfd_ref_ptr. * gcore.h (create_gcore_bfd): Return gdb_bfd_ref_ptr. * gcore.c (create_gcore_bfd): Return gdb_bfd_ref_ptr. (gcore_command): Update. * exec.c (exec_file_attach): Update. * elfread.c (elf_symfile_read): Update. * dwarf2read.c (dwarf2_get_dwz_file): Update. (try_open_dwop_file, open_dwo_file): Return gdb_bfd_ref_ptr. (open_and_init_dwo_file): Update. (open_dwp_file): Return gdb_bfd_ref_ptr. (open_and_init_dwp_file): Update. * corelow.c (core_open): Update. * compile/compile-object-load.c (compile_object_load): Update. * common/gdb_ref_ptr.h (ref_ptr::operator->): New operator. * coffread.c (coff_symfile_read): Update. * cli/cli-dump.c (bfd_openr_or_error, bfd_openw_or_error): Return gdb_bfd_ref_ptr. Rename. (dump_bfd_file, restore_command): Update. * build-id.h (build_id_to_debug_bfd): Return gdb_bfd_ref_ptr. * build-id.c (build_id_to_debug_bfd): Return gdb_bfd_ref_ptr. (find_separate_debug_file_by_buildid): Update.
2016-11-22 02:12:23 +08:00
gdb_bfd_ref_ptr abfd (build_id_to_debug_bfd (build_id->size,
build_id->data));
fix PR symtab/15597 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.
2013-10-09 03:56:15 +08:00
/* Prevent looping on a stripped .debug file. */
if (abfd != NULL
Use class to manage BFD reference counts This introduces a new specialization of gdb::ref_ptr that can be used to manage BFD reference counts. Then it changes most places in gdb to use this new class, rather than explicit reference-counting or cleanups. This patch removes make_cleanup_bfd_unref. If you look you will see a couple of spots using "release" where a use of gdb_bfd_ref_ptr would be cleaner. These will be fixed in the next patch. I think this patch fixes some latent bugs. For example, it seems to me that previously objfpy_add_separate_debug_file leaked a BFD. I'm not 100% certain that the macho_symfile_read_all_oso change is correct. The existing code here is hard for me to follow. One goal of this sort of automated reference counting, though, is to make it more difficult to make logic errors; so hopefully the code is clear now. 2017-01-10 Tom Tromey <tom@tromey.com> * windows-tdep.c (windows_xfer_shared_library): Update. * windows-nat.c (windows_make_so): Update. * utils.h (make_cleanup_bfd_unref): Remove. * utils.c (do_bfd_close_cleanup, make_cleanup_bfd_unref): Remove. * symfile.h (symfile_bfd_open) (find_separate_debug_file_in_section): Return gdb_bfd_ref_ptr. * symfile.c (read_symbols, symbol_file_add) (separate_debug_file_exists): Update. (symfile_bfd_open): Return gdb_bfd_ref_ptr. (generic_load, reread_symbols): Update. * symfile-mem.c (symbol_file_add_from_memory): Update. * spu-linux-nat.c (spu_bfd_open): Return gdb_bfd_ref_ptr. (spu_symbol_file_add_from_memory): Update. * solist.h (struct target_so_ops) <bfd_open>: Return gdb_bfd_ref_ptr. (solib_bfd_fopen, solib_bfd_open): Return gdb_bfd_ref_ptr. * solib.c (solib_bfd_fopen, solib_bfd_open): Return gdb_bfd_ref_ptr. (solib_map_sections, reload_shared_libraries_1): Update. * solib-svr4.c (enable_break): Update. * solib-spu.c (spu_bfd_fopen): Return gdb_bfd_ref_ptr. * solib-frv.c (enable_break2): Update. * solib-dsbt.c (enable_break): Update. * solib-darwin.c (gdb_bfd_mach_o_fat_extract): Return gdb_bfd_ref_ptr. (darwin_solib_get_all_image_info_addr_at_init): Update. (darwin_bfd_open): Return gdb_bfd_ref_ptr. * solib-aix.c (solib_aix_bfd_open): Return gdb_bfd_ref_ptr. * record-full.c (record_full_save): Update. * python/py-objfile.c (objfpy_add_separate_debug_file): Update. * procfs.c (insert_dbx_link_bpt_in_file): Update. * minidebug.c (find_separate_debug_file_in_section): Return gdb_bfd_ref_ptr. * machoread.c (macho_add_oso_symfile): Change abfd to gdb_bfd_ref_ptr. (macho_symfile_read_all_oso): Update. (macho_check_dsym): Return gdb_bfd_ref_ptr. (macho_symfile_read): Update. * jit.c (bfd_open_from_target_memory): Return gdb_bfd_ref_ptr. (jit_bfd_try_read_symtab): Update. * gdb_bfd.h (gdb_bfd_open, gdb_bfd_fopen, gdb_bfd_openr) (gdb_bfd_openw, gdb_bfd_openr_iovec) (gdb_bfd_openr_next_archived_file, gdb_bfd_fdopenr): Return gdb_bfd_ref_ptr. (gdb_bfd_ref_policy): New struct. (gdb_bfd_ref_ptr): New typedef. * gdb_bfd.c (gdb_bfd_open, gdb_bfd_fopen, gdb_bfd_openr) (gdb_bfd_openw, gdb_bfd_openr_iovec) (gdb_bfd_openr_next_archived_file, gdb_bfd_fdopenr): Return gdb_bfd_ref_ptr. * gcore.h (create_gcore_bfd): Return gdb_bfd_ref_ptr. * gcore.c (create_gcore_bfd): Return gdb_bfd_ref_ptr. (gcore_command): Update. * exec.c (exec_file_attach): Update. * elfread.c (elf_symfile_read): Update. * dwarf2read.c (dwarf2_get_dwz_file): Update. (try_open_dwop_file, open_dwo_file): Return gdb_bfd_ref_ptr. (open_and_init_dwo_file): Update. (open_dwp_file): Return gdb_bfd_ref_ptr. (open_and_init_dwp_file): Update. * corelow.c (core_open): Update. * compile/compile-object-load.c (compile_object_load): Update. * common/gdb_ref_ptr.h (ref_ptr::operator->): New operator. * coffread.c (coff_symfile_read): Update. * cli/cli-dump.c (bfd_openr_or_error, bfd_openw_or_error): Return gdb_bfd_ref_ptr. Rename. (dump_bfd_file, restore_command): Update. * build-id.h (build_id_to_debug_bfd): Return gdb_bfd_ref_ptr. * build-id.c (build_id_to_debug_bfd): Return gdb_bfd_ref_ptr. (find_separate_debug_file_by_buildid): Update.
2016-11-22 02:12:23 +08:00
&& filename_cmp (bfd_get_filename (abfd.get ()),
fix PR symtab/15597 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.
2013-10-09 03:56:15 +08:00
objfile_name (objfile)) == 0)
Use class to manage BFD reference counts This introduces a new specialization of gdb::ref_ptr that can be used to manage BFD reference counts. Then it changes most places in gdb to use this new class, rather than explicit reference-counting or cleanups. This patch removes make_cleanup_bfd_unref. If you look you will see a couple of spots using "release" where a use of gdb_bfd_ref_ptr would be cleaner. These will be fixed in the next patch. I think this patch fixes some latent bugs. For example, it seems to me that previously objfpy_add_separate_debug_file leaked a BFD. I'm not 100% certain that the macho_symfile_read_all_oso change is correct. The existing code here is hard for me to follow. One goal of this sort of automated reference counting, though, is to make it more difficult to make logic errors; so hopefully the code is clear now. 2017-01-10 Tom Tromey <tom@tromey.com> * windows-tdep.c (windows_xfer_shared_library): Update. * windows-nat.c (windows_make_so): Update. * utils.h (make_cleanup_bfd_unref): Remove. * utils.c (do_bfd_close_cleanup, make_cleanup_bfd_unref): Remove. * symfile.h (symfile_bfd_open) (find_separate_debug_file_in_section): Return gdb_bfd_ref_ptr. * symfile.c (read_symbols, symbol_file_add) (separate_debug_file_exists): Update. (symfile_bfd_open): Return gdb_bfd_ref_ptr. (generic_load, reread_symbols): Update. * symfile-mem.c (symbol_file_add_from_memory): Update. * spu-linux-nat.c (spu_bfd_open): Return gdb_bfd_ref_ptr. (spu_symbol_file_add_from_memory): Update. * solist.h (struct target_so_ops) <bfd_open>: Return gdb_bfd_ref_ptr. (solib_bfd_fopen, solib_bfd_open): Return gdb_bfd_ref_ptr. * solib.c (solib_bfd_fopen, solib_bfd_open): Return gdb_bfd_ref_ptr. (solib_map_sections, reload_shared_libraries_1): Update. * solib-svr4.c (enable_break): Update. * solib-spu.c (spu_bfd_fopen): Return gdb_bfd_ref_ptr. * solib-frv.c (enable_break2): Update. * solib-dsbt.c (enable_break): Update. * solib-darwin.c (gdb_bfd_mach_o_fat_extract): Return gdb_bfd_ref_ptr. (darwin_solib_get_all_image_info_addr_at_init): Update. (darwin_bfd_open): Return gdb_bfd_ref_ptr. * solib-aix.c (solib_aix_bfd_open): Return gdb_bfd_ref_ptr. * record-full.c (record_full_save): Update. * python/py-objfile.c (objfpy_add_separate_debug_file): Update. * procfs.c (insert_dbx_link_bpt_in_file): Update. * minidebug.c (find_separate_debug_file_in_section): Return gdb_bfd_ref_ptr. * machoread.c (macho_add_oso_symfile): Change abfd to gdb_bfd_ref_ptr. (macho_symfile_read_all_oso): Update. (macho_check_dsym): Return gdb_bfd_ref_ptr. (macho_symfile_read): Update. * jit.c (bfd_open_from_target_memory): Return gdb_bfd_ref_ptr. (jit_bfd_try_read_symtab): Update. * gdb_bfd.h (gdb_bfd_open, gdb_bfd_fopen, gdb_bfd_openr) (gdb_bfd_openw, gdb_bfd_openr_iovec) (gdb_bfd_openr_next_archived_file, gdb_bfd_fdopenr): Return gdb_bfd_ref_ptr. (gdb_bfd_ref_policy): New struct. (gdb_bfd_ref_ptr): New typedef. * gdb_bfd.c (gdb_bfd_open, gdb_bfd_fopen, gdb_bfd_openr) (gdb_bfd_openw, gdb_bfd_openr_iovec) (gdb_bfd_openr_next_archived_file, gdb_bfd_fdopenr): Return gdb_bfd_ref_ptr. * gcore.h (create_gcore_bfd): Return gdb_bfd_ref_ptr. * gcore.c (create_gcore_bfd): Return gdb_bfd_ref_ptr. (gcore_command): Update. * exec.c (exec_file_attach): Update. * elfread.c (elf_symfile_read): Update. * dwarf2read.c (dwarf2_get_dwz_file): Update. (try_open_dwop_file, open_dwo_file): Return gdb_bfd_ref_ptr. (open_and_init_dwo_file): Update. (open_dwp_file): Return gdb_bfd_ref_ptr. (open_and_init_dwp_file): Update. * corelow.c (core_open): Update. * compile/compile-object-load.c (compile_object_load): Update. * common/gdb_ref_ptr.h (ref_ptr::operator->): New operator. * coffread.c (coff_symfile_read): Update. * cli/cli-dump.c (bfd_openr_or_error, bfd_openw_or_error): Return gdb_bfd_ref_ptr. Rename. (dump_bfd_file, restore_command): Update. * build-id.h (build_id_to_debug_bfd): Return gdb_bfd_ref_ptr. * build-id.c (build_id_to_debug_bfd): Return gdb_bfd_ref_ptr. (find_separate_debug_file_by_buildid): Update.
2016-11-22 02:12:23 +08:00
warning (_("\"%s\": separate debug info file has no debug info"),
bfd_get_filename (abfd.get ()));
fix PR symtab/15597 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.
2013-10-09 03:56:15 +08:00
else if (abfd != NULL)
return std::string (bfd_get_filename (abfd.get ()));
fix PR symtab/15597 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.
2013-10-09 03:56:15 +08:00
}
return std::string ();
fix PR symtab/15597 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.
2013-10-09 03:56:15 +08:00
}