mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2025-04-12 14:33:06 +08:00
52c5091dfb
In PR gdb/31846 the user reported an issue where GDB is unable to find the build-id within an ELF, despite the build-id being present (confirmed using readelf). The user was able to try several different builds of GDB, and in one build they observed the warning: warning: BFD: FILENAME: unable to decompress section .debug_info But in may other builds of GDB this warning was missing. There are, I think, a couple of issues that the user is running into, but this patch is about why the above warning is often missing from GDB's output. I wasn't able to reproduce a corrupted .debug_info section such that the above warning would be triggered, but it is pretty easy to patch the _bfd_elf_make_section_from_shdr function (in bfd/elf.c) such that the call to bfd_init_section_decompress_status is reported as a failure, thus triggering the warning. There is a patch that achieves this in the bug report. I did this, and can confirm that on my build of GDB, I don't see the above warning, even though I can confirm that the _bfd_error_handler call (in _bfd_elf_make_section_from_shdr) is being reached. The problem is back in format.c, in bfd_check_format_matches. This function intercepts all the warnings and places them into a per_xvec_messages structure. These warnings are then printed with a call to print_and_clear_messages. If bfd_check_format_matches finds a single matching format, then print_and_clear_messages, will print all warnings associated with that single format. But if no format matches, print_and_clear_messages will print all the warnings, so long as all targets have emitted the same set of warnings, and unfortunately, that is not the case for me. The warnings are collected by iterating over bfd_target_vector and trying each target. My target happens to be x86_64_elf64_vec, and, as expected this target appears in bfd_target_vector. However, bfd_target_vector also includes DEFAULT_VECTOR near the top. And in my build, DEFAULT_VECTOR is x86_64_elf64_vec. Thus, for me, the x86_64_elf64_vec entry appears twice in bfd_target_vector, this means that x86_64_elf64_vec ends up being tried twice, and, as each try generates one warning, the x86_64_elf64_vec entry in the per_xvec_messages structure, has two warnings, while the other per_xvec_messages entries only have one copy of the warning. Because of this difference, print_and_clear_messages decides not to print any of the warnings, which is not very helpful. I considered a few different approaches to fix this issue: We could de-duplicate warnings in the per_xvec_messages structure as new entries are added. So for any particular xvec, each time a new warning arrives, if the new warning is identical to an existing warning, then don't record it. This might be an interesting change in the future, but for now I rejected this solution as it felt like a bodge, the duplicate warnings aren't really from a single attempt at an xvec, but are from two distinct attempts at the same xvec. And so: I wondered if we could remove the duplicate entries from bfd_target_vector. Or if we could avoid processing the same xvec twice maybe? For the single DEFAULT_VECTOR this wouldn't be too hard to do, but bfd_target_vector also includes SELECT_VECS, which I think could contain more duplicates. Changing bfd_check_format_matches to avoid attempting any duplicate vectors would now require more complexity than a single flag, and I felt there was an easier solution, which was: I propose that within bfd_check_format_matches, within the loop that tries each entry from bfd_target_vector, as we switch to each vector in turn, we should delete any existing warnings within the per_xvec_messages structure for the target vector we are about to try. This means that, if we repeat a target, only the last set of warnings will survive. With this change in place, print_and_clear_messages now sees the same set of warnings for each target, and so prints out the warning message. Additionally, while I was investigating this issue I managed to call print_and_clear_messages twice. This caused a crash because the first call to print_and_clear_messages frees all the associated memory, but leaves the per_xvec_messages::next field pointing to the now deallocated object. I'd like to propose that we set the next field to NULL in print_and_clear_messages. This clearly isn't needed so long as print_and_clear_messages is only called once, but (personally) I like to set pointers back to NULL if the object they are pointing to is free and the parent object is going to live for some additional time. I can drop this extra change if people don't like it. This change doesn't really "fix" PR gdb/31846, but it does mean that the warning about being unable to decompress .debug_info should now be printed consistently, which is a good thing. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31846 Reviewed-By: Alan Modra <amodra@gmail.com>
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.