cd2bb70994
While experimenting with the previous patch, I noticed this inconsistency
in GDB's output:
(gdb) b 32
Breakpoint 1 at 0x40062f: file inline-break.c, line 32. (1)
(gdb) r
....
Breakpoint 1, func1 (x=1) at inline-break.c:32 (2)
32 return x * 23; /* break here */
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x40062f in main at inline-break.c:32 (3)
breakpoint already hit 1 time
(gdb)
Notice that when the breakpoint as set, GDB showed "inline-break.c,
line 32" (1), the same line number that was specified in the command.
When we run to the breakpoint, we present the stop at the same line
number, and correctly show "func1" as the function name (2).
But in "info break" output (3), notice that we say "in main", not "in
func1".
The same thing happens if you set a breakpoint by address. I.e.:
(gdb) b *0x40062f
Breakpoint 2 at 0x40062f: file inline-break.c, line 32.
(gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep y 0x000000000040062f in main at inline-break.c:32
(gdb) r
....
Breakpoint 2, func1 (x=1) at inline-break.c:32
32 return x * 23; /* break here */
The problem is that the breakpoints were set at an inline function,
but when we set such a breakpoint by line number or address, we don't
record the functions symbol in the sal, and as consequence the
breakpoint location does not have an associated symbol either.
Then, in print_breakpoint_location, if the location does not have a
symbol, we call find_pc_sect_function to find one, and this is what
finds "main", because find_pc_sect_function uses
block_linkage_function:
/* Return the symbol for the function which contains a specified
lexical block, described by a struct block BL. The return value
will not be an inlined function; the containing function will be
returned instead. */
struct symbol *
block_linkage_function (const struct block *bl)
To fix this, this commit adds an alternative to find_pc_sect_function
that uses block_containing_function instead:
/* Return the symbol for the function which contains a specified
block, described by a struct block BL. The return value will be
the closest enclosing function, which might be an inline
function. */
struct symbol *
block_containing_function (const struct block *bl)
(It seems odd to me that block_linkage_function says "the CONTAINING
function will be returned", and then block_containing_function says it
returns "the closest enclosing function". Something seems reversed
here. Still, I've kept the same nomenclature and copied the comments,
so that at least there's consistency. Maybe we should fix that up
somehow.)
Then I wondered, why make print_breakpoint_location look up the symbol
every time it is called, instead of just always storing the symbol
when the location is created, since the location already stores the
symbol in some cases. So to find which cases might be missing setting
the symbol in the sal which is used to create the breakpoint location,
I added an assertion to print_breakpoint_location, and ran the
testsuite. That caught a few places, unsurprisingly:
- setting a breakpoint by line number
- setting a breapoint by address
- ifunc resolving
Those are all fixed by this commit. I decided not to add the
assertion to block_linkage_function and leave the existing "if (sym)"
check in place, because it's plausible that we have symtabs with line
info but no symbols. I.e., that would not be a GDB bug, but
a peculiarity of debug info input.
gdb/ChangeLog:
2018-06-29 Pedro Alves <palves@redhat.com>
* blockframe.c (find_pc_sect_containing_function): New function.
* breakpoint.c (print_breakpoint_location): Don't call
find_pc_sect_function.
* linespec.c (create_sals_line_offset): Record the location's
symbol in the sal.
* linespec.c (convert_address_location_to_sals): Fill in sal's
symbol with find_pc_sect_containing_function.
* symtab.c (find_function_start_sal): Rename to ...
(find_function_start_sal_1): ... this.
(find_function_start_sal): Reimplement as wrapper around
find_function_start_sal_1, and use
find_pc_sect_containing_function to fill in the sal's symbol.
(find_function_start_sal(symbol*, bool)): Adjust.
* symtab.h (find_pc_function, find_pc_sect_function): Adjust
comments.
(find_pc_sect_containing_function): Declare.
gdb/testsuite/ChangeLog:
2018-06-29 Pedro Alves <palves@redhat.com>
* gdb.opt/inline-break.exp (line number, address): Add "info
break" tests.
|
||
|---|---|---|
| bfd | ||
| binutils | ||
| config | ||
| cpu | ||
| elfcpp | ||
| etc | ||
| gas | ||
| gdb | ||
| gold | ||
| gprof | ||
| include | ||
| intl | ||
| ld | ||
| 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 | ||
| 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.