Andrew Burgess
ef56b00650
This commit adds a test for the following commit:
commit e86e87f77f
Date: Tue Nov 28 16:23:32 2006 +0000
* symtab.c (find_pc_sect_line): Do not return a line before
the start of a symtab.
We have been carrying a test for that commit in the Fedora GDB tree
since that commit was added to GDB. I don't know why the test wasn't
added along with the original commit, but as was written, the test is
pretty gross, it uses objcopy to pull the .text section from an object
file, which was then injected into another source file within a .asm
statement...
... these days we can just make use of the DWARF assembler to achieve
the same results, so I've rewritten the test and think it is worth
adding this to upstream GDB.
The original patch was about about how we find the best symtab and
line table entry, and what to do when GDB can't find a good match.
The new test creates a CU with two functions, only one of which is
covered by the line table. With the above patch reverted GDB returns
an invalid address.
With the above patch reverted I did run the testsuite to see what
other tests might already be exercising this functionality, and I
found two tests:
gdb.dwarf2/dw2-step-out-of-function-no-stmt.exp
gdb.dwarf2/dw2-vendor-extended-opcode.exp
These are pretty similar, they either create minimal, or no line table
for one of the functions in the source file, and as a consequence GDB
returns an unexpected address at some point during the test.
However, both of those tests are really focused on other issues, so I
think this new test does add some value. Plus the new test is not
large, so it's not a huge cost to also run this new test.
Reviewed-By: Tom Tromey <tom@tromey.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.