1fd999d909
While messing with the Dwarf assembler (gdb/testsuite/lib/dwarf.exp) I managed to create an ELF which made use of DW_FORM_strp, but didn't include a .debug_str section. When I started GDB on this ELF, GDB crashed. I would have expected to get an error instead. I tracked this down to an unfortunate design choice in dwarf2_section_info, a class which wraps around a bfd section, and is used for reading in debug information. GBB creates many dwarf2_section_info objects, one for each debug section that might need to be read, then as we find the input bfd sections we associate them with the corresponding dwarf2_section_info. If no matching input bfd section is found then the dwarf2_section_info is left in an unassociated state, its internal bfd section pointer is null. If later GDB tries to read content from the dwarf2_section_info, for example, which trying to read the string associated with DW_FORM_strp, we spot that there is no associated bfd section and issue an error message. To make the users life easier, the error message includes the section name being looked for, and the bfd from which the section was obtained. However, we get the section name by calling bfd_section_name on the associated section, and we get the bfd filename by calling bfd_get_filename on the owner of the associated section. Of course, if there is no associated section then both the calls bfd_section_name and dwarf2_section_info::get_bfd_owner will result in undefined behaviour (e.g. a crash). The solution I propose in this patch is, I know, not ideal. I simply spot the case where there is no associated section, and print a simpler error message, leaving out the section name and filename. A better solution would involve redesigning dwarf2_section_info, we could associate each dwarf2_section_info with the initial bfd being parsed. We would then display this filename if there's nothing better to display (e.g. if we find a section in a dwo/dwp split dwarf file then we would probably use that filename in preference). Each dwarf2_section_info could also have the concept of the default section name that would be read for that section, for example, string data might appear in ".debug_str" or ".zdebug_str", but if neither is found, then it would probably be OK to just say ".debug_str" is missing. Anyway, I didn't do any of that redesign, I just wanted to stop GDB crashing for now, so instead we get this: Dwarf Error: DW_FORM_strp used without required section Which isn't the best, but in context, isn't too bad: Reading symbols from /path/to/executable... Dwarf Error: DW_FORM_strp used without required section (No debugging symbols found in /path/to/executable) I also added some asserts into dwarf2_section_info which should trigger before GDB crashes in future, if we trigger any other bad paths through this code. And there's a test for the specific issue I hit. gdb/ChangeLog: * dwarf2/section.c (dwarf2_section_info::get_bfd_owner): Add an assert. (dwarf2_section_info::get_file_name): Add an assert. (dwarf2_section_info::read_string): Display a minimal, sane error when the dwarf2_section_info is not associated with a bfd section. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-using-debug-str.exp: Add an additional test. |
||
|---|---|---|
| bfd | ||
| binutils | ||
| config | ||
| contrib | ||
| cpu | ||
| elfcpp | ||
| etc | ||
| gas | ||
| gdb | ||
| gdbserver | ||
| gdbsupport | ||
| gnulib | ||
| gold | ||
| gprof | ||
| include | ||
| intl | ||
| ld | ||
| libctf | ||
| libdecnumber | ||
| libiberty | ||
| opcodes | ||
| readline | ||
| sim | ||
| texinfo | ||
| zlib | ||
| .cvsignore | ||
| .gitattributes | ||
| .gitignore | ||
| ar-lib | ||
| ChangeLog | ||
| compile | ||
| config-ml.in | ||
| config.guess | ||
| config.rpath | ||
| config.sub | ||
| configure | ||
| configure.ac | ||
| COPYING | ||
| COPYING3 | ||
| COPYING3.LIB | ||
| COPYING.LIB | ||
| COPYING.LIBGLOSS | ||
| COPYING.NEWLIB | ||
| depcomp | ||
| djunpack.bat | ||
| install-sh | ||
| libtool.m4 | ||
| lt~obsolete.m4 | ||
| ltgcc.m4 | ||
| ltmain.sh | ||
| ltoptions.m4 | ||
| ltsugar.m4 | ||
| ltversion.m4 | ||
| MAINTAINERS | ||
| Makefile.def | ||
| Makefile.in | ||
| Makefile.tpl | ||
| makefile.vms | ||
| missing | ||
| mkdep | ||
| mkinstalldirs | ||
| move-if-change | ||
| multilib.am | ||
| README | ||
| README-maintainer-mode | ||
| setup.com | ||
| src-release.sh | ||
| symlink-tree | ||
| test-driver | ||
| ylwrap | ||
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.