mirror/binutils-gdb
2
0
Fork 0
mirror of https://sourceware.org/git/binutils-gdb.git synced 2025-02-17 13:10:12 +08:00
Code Issues Packages Projects Releases Wiki Activity
119,822 Commits 392 Branches 138 Tags 634 MiB
C 51.3%
Makefile 22.7%
Assembly 12.5%
C++ 5.9%
Roff 1.4%
Other 5.6%
912bc231ab
Go to file
Tom de Vries 912bc231ab [gdb/python] Add gdbpy_handle_gdb_exception 
I've recently committed two patches:
- commit 2f8cd40c37 ("[gdb/python] Use GDB_PY_HANDLE_EXCEPTION more often")
- commit fbf8e4c35c ("[gdb/python] Use GDB_PY_SET_HANDLE_EXCEPTION more often")
which use the macros GDB_PY_HANDLE_EXCEPTION and GDB_PY_SET_HANDLE_EXCEPTION
more often, with the goal of making things more consistent.

Having done that, I wondered if a better approach could be possible.

Consider GDB_PY_HANDLE_EXCEPTION:
...
 /* Use this in a 'catch' block to convert the exception to a Python
    exception and return nullptr.  */
 #define GDB_PY_HANDLE_EXCEPTION(Exception)	\
   do {						\
     gdbpy_convert_exception (Exception);	\
     return nullptr;				\
   } while (0)
...

The macro nicely codifies how python handles exceptions:
- setting an error condition using some PyErr_Set* variant, and
- returning a value implying that something went wrong
presumably with the goal that using the macro will mean not accidentally:
- forgetting to return on error, or
- returning the wrong value on error.

The problems are that:
- the macro hides control flow, specifically the return statement, and
- the macro hides the return value.

For example, when reading somewhere:
...
  catch (const gdb_exception &except)
    {
      GDB_PY_HANDLE_EXCEPTION (except);
    }
...
in order to understand what this does, you have to know that the macro
returns, and that it returns nullptr.

Add a template gdbpy_handle_gdb_exception:
...
template<typename T>
[[nodiscard]] T
gdbpy_handle_gdb_exception (T val, const gdb_exception &e)
{
  gdbpy_convert_exception (e);
  return val;
}
...
which can be used instead:
...
  catch (const gdb_exception &except)
    {
      return gdbpy_handle_gdb_exception (nullptr, except);
    }
...

[ Initially I tried this:
...
template<auto val>
[[nodiscard]] auto
gdbpy_handle_gdb_exception (const gdb_exception &e)
{
  gdbpy_convert_exception (e);
  return val;
}
...
with which the usage is slightly better looking:
...
  catch (const gdb_exception &except)
    {
      return gdbpy_handle_gdb_exception<nullptr> (except);
    }
...
but I ran into trouble with older gcc compilers. ]

While still a single statement, we now have it clear:
- that the statement returns,
- what value the statement returns.

[ FWIW, this could also be handled by say:
...
-      GDB_PY_HANDLE_EXCEPTION (except);
+      GDB_PY_HANDLE_EXCEPTION_AND_RETURN_VAL (except, nullptr);
...
but I still didn't find the fact that it returns easy to spot.

Alternatively, this is the simplest form we could use:
...
      return gdbpy_convert_exception (e), nullptr;
...
but the pairing would not necessarily survive a copy/paste/edit cycle. ]

Also note how making the value explicit makes it easier to check for
consistency:
...
  catch (const gdb_exception &except)
    {
      return gdbpy_handle_gdb_exception (-1, except);
    }

  if (PyErr_Occurred ())
    return -1;
...
given that we do use the explicit constants almost everywhere else.

Compared to using GDB_PY_HANDLE_EXCEPTION, there is the burden now to specify
the return value, but I assume that this will be generally copy-pasted and
therefore present no problem.

Also, there's no longer a guarantee that there's an immediate return, but I
assume that nodiscard making sure that the return value is not silently
ignored is sufficient mitigation.

For now, re-implement GDB_PY_HANDLE_EXCEPTION and GDB_PY_SET_HANDLE_EXCEPTION
in terms of gdbpy_handle_gdb_exception.

Follow-up patches will eliminate the macros.

No functional changes.

Tested on x86_64-linux.

Approved-By: Tom Tromey <tom@tromey.com>
2024-09-24 13:06:32 +02:00
bfd Automatic date update in version.in 2024-09-24 00:00:35 +00:00
binutils get_type_abbrev_from_form tidy 2024-08-29 21:05:57 +09:30
config
contrib Revert "contrib: Add autoregen.py" 2024-09-04 13:38:57 +00:00
cpu
elfcpp
etc
gas x86: Enable TLS relocation check only for ELF 2024-09-24 05:52:43 +08:00
gdb [gdb/python] Add gdbpy_handle_gdb_exception 2024-09-24 13:06:32 +02:00
gdbserver gdbserver: aarch64: Fix expedited registers list 2024-09-05 01:02:51 -03:00
gdbsupport gdbsupport/intrusive-list: add owning_intrusive_list 2024-09-13 07:38:56 -04:00
gnulib
gold gold: Always resolve non-default weak undefined to 0 2024-08-31 04:28:43 -07:00
gprof
gprofng Fix 32096 UBSAN issues in gprofng 2024-09-18 20:24:24 -07:00
include MIPS/opcodes: Rework documentation for instruction args 2024-09-15 13:27:33 +01:00
ld ld/pdb: Handle DEBUG_S_INLINEELINES data 2024-09-24 02:33:08 +01:00
libbacktrace
libctf PR32093, -Walloc-size warning in ctf-hash.c 2024-08-29 21:05:57 +09:30
libdecnumber
libiberty libiberty: sync with gcc 2024-09-04 15:35:42 +01:00
libsframe
opcodes x86/APX: Don't promote AVX/AVX2 instructions out of APX spec 2024-09-18 10:11:02 +08:00
readline
sim
texinfo
zlib
.cvsignore
.editorconfig
.gitattributes
.gitignore
.pre-commit-config.yaml
ar-lib
ChangeLog
compile
config-ml.in
config.guess
config.rpath
config.sub
configure Disable gprofng build for *musl* 2024-08-26 13:48:29 -07:00
configure.ac Disable gprofng build for *musl* 2024-08-26 13:48:29 -07:00
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
multilib.am
README
README-maintainer-mode
SECURITY.txt
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.