mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2025-03-13 13:49:00 +08:00
The documentation for Progspace.block_for_pc says: Return the innermost gdb.Block containing the given pc value. If the block cannot be found for the pc value specified, the function will return None. However, the implementation actually throws an error for invalid addresses, like this: (gdb) python print gdb.current_progspace ().block_for_pc (1) Traceback (most recent call last): File "<string>", line 1, in <module> RuntimeError: Cannot locate object file for block. Error while executing Python code. (gdb) This has been the behaviour since the command was first added (when the documentation was still as above) in this commit: commit f3e9a8177c41893858fce2bdf339dbe90b3a4ef5 Date: Wed Feb 24 21:18:28 2010 +0000 Since that commit the code in question has moved around, but the important parts are largely unchanged. The function in question is now in py-progspace.c:pspy_block_for_pc. Examining the code shows that the real state is more complex than just the function throws an error instead of returning None, instead the real situation is: 1. If we can't find a compilation unit for the $pc value then we throw an error, but 2. If we can find a compilation unit, but can't find a block within the compilation unit for the $pc then return None. I suspect for most users of the Python API this distinction is irrelevant, and I propose that we standardise on one single failure mechanism. Given the function can currently return None in some cases, and is documented to return None on error, I propose we make that the case for all error paths, which is what this patch does. As the Progspace.block_for_pc method is currently untested, I've added some basic tests including for a call with an invalid $pc. This is potentially an API breaking change, though an undocumented part of the API. Also, users should have been checking and handling a None return value anyway, so my hope is that this shouldn't be too disruptive. gdb/ChangeLog: * python/py-progspace.c (pspy_block_for_pc): Return None for all error paths. gdb/testsuite/ChangeLog: * gdb.python/py-progspace.exp: Add tests for the Progspace.block_for_pc method. Change-Id: I9cea8d2132902bcad0013d1fd39080dd5423cc57
…
…
…
…
…
…
…
…
…
…
…
…
…
…
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.
Description
Languages
C
51.3%
Makefile
22.7%
Assembly
12.5%
C++
5.9%
Roff
1.4%
Other
5.6%