3d92a3e313
Don't reorder line table entries for the same address when sorting the line table, maintain the compiler given line order. Usually this will reflect the order in which lines are conceptually encountered at a given address. Consider this example: /* 1 */ volatile int global_var; /* 2 */ int __attribute__ ((noinline)) /* 3 */ bar () /* 4 */ { /* 5 */ return global_var; /* 6 */ } /* 7 */ static inline int __attribute__ ((always_inline)) /* 8 */ foo () /* 9 */ { /* 10 */ return bar (); /* 11 */ } /* 12 */ int /* 13 */ main () /* 14 */ { /* 15 */ global_var = 0; /* 16 */ return foo (); /* 17 */ } GCC 10 currently generates a line table like this (as shown by objdump): CU: ./test.c: File name Line number Starting address test.c 4 0x4004b0 test.c 5 0x4004b0 test.c 6 0x4004b6 test.c 6 0x4004b7 test.c 14 0x4003b0 test.c 15 0x4003b0 test.c 16 0x4003ba test.c 10 0x4003ba test.c 10 0x4003c1 The interesting entries are those for lines 16 and 10 at address 0x4003ba, these represent the call to foo and the inlined body of foo. With the current line table sorting GDB builds the line table like this (as shown by 'maintenance info line-table'): INDEX LINE ADDRESS 0 14 0x00000000004003b0 1 15 0x00000000004003b0 2 10 0x00000000004003ba 3 16 0x00000000004003ba 4 END 0x00000000004003c1 5 4 0x00000000004004b0 6 5 0x00000000004004b0 7 END 0x00000000004004b7 Notice that entries 2 and 3 for lines 10 and 16 are now in a different order to the line table as given by the compiler. With this patch applied the order is now: INDEX LINE ADDRESS 0 14 0x00000000004003b0 1 15 0x00000000004003b0 2 16 0x00000000004003ba 3 10 0x00000000004003ba 4 END 0x00000000004003c1 5 4 0x00000000004004b0 6 5 0x00000000004004b0 7 END 0x00000000004004b7 Notice that entries 2 and 3 are now in their original order again. The consequence of the incorrect ordering is that when stepping through inlined functions GDB will display the wrong line for the inner most frame. Here's a GDB session before this patch is applied: Starting program: /home/andrew/tmp/inline/test Temporary breakpoint 1, main () at test.c:15 15 /* 15 */ global_var = 0; (gdb) step 16 /* 16 */ return foo (); (gdb) step foo () at test.c:16 16 /* 16 */ return foo (); (gdb) step bar () at test.c:5 5 /* 5 */ return global_var; The step from line 15 to 16 was fine, but the next step should have taken us to line 10, instead we are left at line 16. The final step to line 5 is as expected. With this patch applied the session goes better: Starting program: /home/andrew/tmp/inline/test Temporary breakpoint 1, main () at test.c:15 15 /* 15 */ global_var = 0; (gdb) step 16 /* 16 */ return foo (); (gdb) step foo () at test.c:10 10 /* 10 */ return bar (); (gdb) step bar () at test.c:5 5 /* 5 */ return global_var; We now visit the lines as 15, 16, 10, 5 as we would like. The reason for this issue is that the inline frame unwinder is detecting that foo is inlined in main. When we stop at the shared address 0x4003ba the inline frame unwinder first shows us the outer frame, this information is extracted from the DWARF's DW_TAG_inlined_subroutine entries and passed via GDB's block data. When we step again the inlined frame unwinder moves us up the call stack to the inner most frame at which point the frame is displayed as normal, with the location for the address being looked up in the line table. As GDB uses the last line table entry for an address as "the" line to report for that address it is critical that GDB maintain the order of the line table entries. In the first case, by reordering the line table we report the wrong location. I had to make a small adjustment in find_pc_sect_line in order to correctly find the previous line in the line table. In some line tables I was seeing an actual line entry and an end of sequence marker at the same address, before this commit these would reorder to move the end of sequence marker before the line entry (end of sequence has line number 0). Now the end of sequence marker remains in its correct location, and in order to find a previous line we should step backward over any end of sequence markers. As an example, the binary: gdb/testsuite/outputs/gdb.dwarf2/dw2-ranges-func/dw2-ranges-func-lo-cold Has this line table before the patch: INDEX LINE ADDRESS 0 48 0x0000000000400487 1 END 0x000000000040048e 2 52 0x000000000040048e 3 54 0x0000000000400492 4 56 0x0000000000400497 5 END 0x000000000040049a 6 62 0x000000000040049a 7 END 0x00000000004004a1 8 66 0x00000000004004a1 9 68 0x00000000004004a5 10 70 0x00000000004004aa 11 72 0x00000000004004b9 12 END 0x00000000004004bc 13 76 0x00000000004004bc 14 78 0x00000000004004c0 15 80 0x00000000004004c5 16 END 0x00000000004004cc And after this patch: INDEX LINE ADDRESS 0 48 0x0000000000400487 1 52 0x000000000040048e 2 END 0x000000000040048e 3 54 0x0000000000400492 4 56 0x0000000000400497 5 END 0x000000000040049a 6 62 0x000000000040049a 7 66 0x00000000004004a1 8 END 0x00000000004004a1 9 68 0x00000000004004a5 10 70 0x00000000004004aa 11 72 0x00000000004004b9 12 END 0x00000000004004bc 13 76 0x00000000004004bc 14 78 0x00000000004004c0 15 80 0x00000000004004c5 16 END 0x00000000004004cc When calling find_pc_sect_line with the address 0x000000000040048e, in both cases we find entry #3, we then try to find the previous entry, which originally found this entry '2 52 0x000000000040048e', after the patch it finds '2 END 0x000000000040048e', which cases the lookup to fail. By skipping the END marker after this patch we get back to the correct entry, which is now #1: '1 52 0x000000000040048e', and everything works again. gdb/ChangeLog: * buildsym.c (lte_is_less_than): Delete. (buildsym_compunit::end_symtab_with_blockvector): Create local lambda function to sort line table entries, and use std::stable_sort instead of std::sort. * symtab.c (find_pc_sect_line): Skip backward over end of sequence markers when looking for a previous line. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-inline-stepping.c: New file. * gdb.dwarf2/dw2-inline-stepping.exp: New file. Change-Id: Ia0309494be4cfd9dcc554f30209477f5f040b21b |
||
---|---|---|
bfd | ||
binutils | ||
config | ||
contrib | ||
cpu | ||
elfcpp | ||
etc | ||
gas | ||
gdb | ||
gdbsupport | ||
gnulib | ||
gold | ||
gprof | ||
include | ||
intl | ||
ld | ||
libctf | ||
libdecnumber | ||
libiberty | ||
opcodes | ||
readline | ||
sim | ||
texinfo | ||
zlib | ||
.cvsignore | ||
.gitattributes | ||
.gitignore | ||
COPYING | ||
COPYING.LIB | ||
COPYING.LIBGLOSS | ||
COPYING.NEWLIB | ||
COPYING3 | ||
COPYING3.LIB | ||
ChangeLog | ||
MAINTAINERS | ||
Makefile.def | ||
Makefile.in | ||
Makefile.tpl | ||
README | ||
README-maintainer-mode | ||
ar-lib | ||
compile | ||
config-ml.in | ||
config.guess | ||
config.rpath | ||
config.sub | ||
configure | ||
configure.ac | ||
depcomp | ||
djunpack.bat | ||
install-sh | ||
libtool.m4 | ||
ltgcc.m4 | ||
ltmain.sh | ||
ltoptions.m4 | ||
ltsugar.m4 | ||
ltversion.m4 | ||
lt~obsolete.m4 | ||
makefile.vms | ||
missing | ||
mkdep | ||
mkinstalldirs | ||
move-if-change | ||
multilib.am | ||
setup.com | ||
src-release.sh | ||
symlink-tree | ||
test-driver | ||
ylwrap |
README
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.