mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-26 13:56:22 +08:00
90ed9b8bc1
When parsing DWARF data in order to report file/line type error messages we perform section placement to make section addresses unique within relocatable object files. Currently, if we reuse previously loaded (and cached) dwarf data then we neglect to perform section placement, the result is that the section addresses will not be unique, and we might, incorrectly associate an address with the wrong debug information, and so report an incorrect file and line number. Further we neglect to check that that bfd for which we are looking up debug information is actually the bfd for which the previous debug information was loaded, it is possible that we will reuse previously loaded debug information for a different bfd. And finally, due to following of gnu_debuglink links in one bfd to another, the process of checking that the cached debug information is valid requires us to track the original bfd in the cached debug information. The original debug information here is either the bfd that we're interested in, not the bfd we finally load the debug information from. bfd/ChangeLog: * dwarf2.c (struct dwarf2_debug): Add orig_bfd member. (_bfd_dwarf2_slurp_debug_info): If stashed debug information does not match current bfd, then reload debug information. Record bfd we're loading debug info for in the stash. If we have debug informatin in the cache then perform section placement before returning. ld/ChangeLog: * testsuite/ld-elf/dwarf.exp (build_tests): Add new tests. * testsuite/ld-elf/dwarf2.err: New file. * testsuite/ld-elf/dwarf2a.c: New file. * testsuite/ld-elf/dwarf2b.c: New file. * testsuite/ld-elf/dwarf3.c: New file. * testsuite/ld-elf/dwarf3.err: New file.
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.