2009-03-30 19:54:33 +00:00
|
|
|
|
/* Python interface to stack frames
|
|
|
|
|
|
|
2026-01-05 08:13:29 -07:00
|
|
|
|
Copyright (C) 2008-2026 Free Software Foundation, Inc.
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
|
|
|
|
|
This file is part of GDB.
|
|
|
|
|
|
|
|
|
|
|
|
This program is free software; you can redistribute it and/or modify
|
|
|
|
|
|
it under the terms of the GNU General Public License as published by
|
|
|
|
|
|
the Free Software Foundation; either version 3 of the License, or
|
|
|
|
|
|
(at your option) any later version.
|
|
|
|
|
|
|
|
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
|
GNU General Public License for more details.
|
|
|
|
|
|
|
|
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
|
|
|
|
along with this program. If not, see <http://www.gnu.org/licenses/>. */
|
|
|
|
|
|
|
2022-12-13 22:34:31 -05:00
|
|
|
|
#include "language.h"
|
2009-03-30 19:54:33 +00:00
|
|
|
|
#include "charset.h"
|
|
|
|
|
|
#include "block.h"
|
|
|
|
|
|
#include "frame.h"
|
|
|
|
|
|
#include "symtab.h"
|
|
|
|
|
|
#include "stack.h"
|
|
|
|
|
|
#include "value.h"
|
|
|
|
|
|
#include "python-internal.h"
|
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
Tom Tromey <tromey@redhat.com>
Thiago Jung Bauermann <bauerman@br.ibm.com>
* python/python.c (_initialize_python): Call
gdbpy_initialize_symtabs, gdbpy_initialize_symbols and
gdbpy_initialize_blocks.
* python/python-internal.h: Declare struct symbol, block and
symtab_and_line. Declare block_object_type and
symbol_object_type
(gdbpy_lookup_symbol gdbpy_block_for_pc)
(symtab_and_line_to_sal_object, symtab_to_symtab_object)
(symbol_to_symbol_object, block_to_block_object)
(gdbpy_initialize_symtabs,gdbpy_initialize_symbols)
(gdbpy_initialize_blocks ): Declare.
* python/py-frame.c (frapy_block, frapy_function, frapy_find_sal)
(frapy_select): Add methods.
(frapy_read_var): Add symbol branch.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-symbol, py-symtab,
py-block.
(SUBDIR_PYTHON_SRCS): Likewise.
(py-symbol.o): New rule.
(py-symtab.o): Likewise.
(py-block.o): Likewise.
* python/py-symbol.c: New file.
* python/py-symtab.c: Likewise.
* python/py-block.c: Likewise.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* Makefile.in: Add py-block and py-symbol.
* gdb.python/py-symbol.exp: New File.
* gdb.python/py-symtab.exp: New File.
* gdb.python/py-block.exp: New File.
* gdb.python/py-symbol.c: New File.
* gdb.python/py-block.c: New File.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Frames In Python): Add block, find_sal, function
and select method descriptions.
(Python API): Add Blocks In Python, Symbols in Python and Symbol
Tables in Python to menu.
(Blocks In Python): New node.
(Symbols In Python): New node.
(Symbol Tables in Python): New node.
2010-02-24 21:18:28 +00:00
|
|
|
|
#include "symfile.h"
|
|
|
|
|
|
#include "objfiles.h"
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
2025-10-25 23:55:29 +01:00
|
|
|
|
struct frame_object : public PyObject
|
|
|
|
|
|
{
|
2009-03-30 19:54:33 +00:00
|
|
|
|
struct frame_id frame_id;
|
|
|
|
|
|
struct gdbarch *gdbarch;
|
Remove redundant typedefs
I was inspired by this patch of Simon's:
https://sourceware.org/pipermail/gdb-patches/2020-November/173522.html
... to remove other typedefs that are no longer necessary now that gdb
uses C++.
I didn't remove absolutely every one -- I didn't touch the tdep files.
However, I removed many of them. In some cases, I removed an existing
different struct tag.
2020-12-04 Tom Tromey <tromey@adacore.com>
* linespec.c (struct linespec_token): Rename; remove typedef.
* guile/scm-block.c (struct block_smob): Remove typedef.
(struct block_syms_progress_smob): Likewise.
* guile/scm-symbol.c (struct symbol_smob): Remove typedef.
* guile/scm-symtab.c (symtab_smob): Remove typedef.
(struct sal_smob): Remove typedef.
* guile/scm-param.c (struct param_smob): Remove typedef.
* guile/scm-progspace.c (struct pspace_smob): Rename.
* guile/scm-objfile.c (struct objfile_smob): Rename.
* guile/scm-iterator.c (struct iterator_smob): Rename.
* guile/scm-frame.c (struct frame_smob): Rename.
* guile/scm-arch.c (struct arch_smob): Rename.
* guile/scm-type.c (struct field_smob): Remove typedef.
(struct type_smob): Rename.
* guile/scm-cmd.c (struct command_smob): Remove typedef.
* guile/scm-ports.c (struct ioscm_memory_port): Remove typedef.
* guile/scm-value.c (struct value_smob): Remove typedef.
* guile/scm-lazy-string.c (lazy_string_smob): Remove typedef.
* guile/guile-internal.h (struct scheme_variable)
(struct scheme_function, struct scheme_integer_constant)
(struct gdb_smob, struct chained_gdb_smob)
(struct eqable_gdb_smob, arch_smob, frame_smob, iterator_smob)
(objfile_smob, pspace_smob, type_smob): Remove typedef.
* guile/scm-pretty-print.c (pretty_printer_smob): Remove typedef.
(struct pretty_printer_worker_smob): Remove typedef.
* guile/scm-exception.c (struct exception_smob): Remove typedef.
* python/py-block.c (struct block_object): Remove typedef.
(block_syms_iterator_object): Update.
(set_block): Update.
(block_syms_iterator_object): Remove typedef.
* python/py-inferior.c (struct membuf_object): Remove typedef.
* python/py-symtab.c (struct symtab_object): Remove typedef.
(set_symtab): Update.
(sal_object): Remove typedef.
(set_sal): Update.
* python/py-frame.c (frame_object): Remove typedef.
* python/py-record-btrace.c (struct btpy_list_object): Remove
typedef.
* python/py-arch.c (struct arch_object): Remove typedef.
* python/py-linetable.c (struct linetable_entry_object)
(linetable_object, struct ltpy_iterator_object): Remove typedef.
* python/py-events.h (eventregistry_object): Remove typedef.
(struct events_object): Remove typedef.
* python/python-internal.h (gdbpy_breakpoint_object): Remove
typedef.
(thread_object): Remove typedef.
* python/py-progspace.c (pspace_object): Remove typedef.
* python/py-value.c (struct value_object): Remove typedef.
* python/py-record.h (recpy_record_object): Remove typedef.
(struct recpy_element_object): Remove typedef.
* python/py-lazy-string.c (lazy_string_object): Remove typedef.
* python/py-objfile.c (objfile_object): Remove typedef.
* python/py-cmd.c (struct cmdpy_object): Remove typedef.
* python/py-type.c (type_object): Remove typedef.
(typy_iterator_object): Update.
(set_type): Update.
(field_object): Remove typedef.
(typy_iterator_object): Remove typedef.
* python/py-registers.c (register_descriptor_iterator_object):
Remove typedef.
(struct register_descriptor_object)
(struct reggroup_iterator_object, struct reggroup_object): Remove
typedef.
* python/py-record.c (recpy_gap_object): Remove typedef.
* python/py-symbol.c (symbol_object): Remove typedef.
(set_symbol): Update.
* python/py-event.h (event_object): Remove typedef.
* python/py-param.c (parmpy_object): Remove typedef.
* python/py-instruction.c (struct py_insn_obj): Remove typedef.
* python/py-unwind.c (struct pending_frame_object): Remove typedef.
(unwind_info_object, struct cached_frame_info): Likewise.
2020-12-04 13:09:43 -07:00
|
|
|
|
};
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
gdb/python: add type traits check for all PyObject sub-classes
All of our custom Python types are created as structs, like this:
struct some_new_type : public PyObject
{
... various fields ...
};
Then instances of this struct are created by calling PyObject_New,
either directly within GDB's C++ code, or within Python when a user's
Python script creates an instance of that class.
The problem is that Python is written in C, and PyObject_New doesn't
call any constructors for `some_new_type`, nor for any of the fields
within `some_new_type`.
If `some_new_type` is Plain Old Data (POD), then this is fine. Or, to
be more C++ specific, if `some_new_type` is trivially default
constructable, then we're fine.
But if a field within `some_new_type` has a non-trivial constructor,
then we're in trouble as that constructor will never be run.
An example of a problematic field type is frame_info_ptr. The
constructor for this type registers the new object with a central
management object, recording the `this` pointer, using this type within
`some_new_type` will not work as expected; frame invalidation will not
show up within the frame_info_ptr as you might expect.
And so, this type trait exists. Whenever a struct is created to define
a new Python type we should add a line like:
static_assert (gdb::is_python_allocatable_v<some_new_type>);
This will fail if any field of `some_new_type` are unsuitable for this
use.
We don't actually check is_trivially_default_constructible here. Some
types, e.g. ui_file_style::color, have non-trivial (or no default)
constructors, but are still safe to use within `some_new_type` because
their constructors just initialise data fields; there's nothing
"special" that the constructor does that cannot be achieved by
assigning the fields after creation with PyObject_New.
What actually matters is that the type is trivially destructible
(Python won't call C++ destructors, so destructors with side effects,
like deregistering from a list, would be skipped) and trivially
copyable (Python may copy objects with memcpy). Types like
frame_info_ptr, whose constructors and destructors have side effects
such as registering with a central management object, will be caught
because they are neither trivially destructible nor trivially copyable.
Simple POD types like ui_file_style are trivially destructible and
copyable, so pass this trait.
This commit adds the new type trait, and makes use of it in all cases
but one, pending_frame_object in python/py-unwind.c, has a field of
type frame_info_ptr, which is currently broken. This will be fixed,
and the static_assert added, in the next commit.
Approved-By: Tom Tromey <tom@tromey.com>
2026-05-14 09:39:57 +01:00
|
|
|
|
static_assert (gdb::is_python_allocatable_v<frame_object>);
|
|
|
|
|
|
|
2009-03-30 19:54:33 +00:00
|
|
|
|
/* Require a valid frame. This must be called inside a TRY_CATCH, or
|
|
|
|
|
|
another context in which a gdb exception is allowed. */
|
|
|
|
|
|
#define FRAPY_REQUIRE_VALID(frame_obj, frame) \
|
|
|
|
|
|
do { \
|
|
|
|
|
|
frame = frame_object_to_frame_info (frame_obj); \
|
|
|
|
|
|
if (frame == NULL) \
|
2010-04-14 13:18:55 +00:00
|
|
|
|
error (_("Frame is invalid.")); \
|
2009-03-30 19:54:33 +00:00
|
|
|
|
} while (0)
|
|
|
|
|
|
|
|
|
|
|
|
/* Returns the frame_info object corresponding to the given Python Frame
|
|
|
|
|
|
object. If the frame doesn't exist anymore (the frame id doesn't
|
|
|
|
|
|
correspond to any frame in the inferior), returns NULL. */
|
|
|
|
|
|
|
2022-07-25 14:06:35 -03:00
|
|
|
|
frame_info_ptr
|
2011-12-23 17:06:16 +00:00
|
|
|
|
frame_object_to_frame_info (PyObject *obj)
|
2009-03-30 19:54:33 +00:00
|
|
|
|
{
|
2013-11-29 12:00:47 -08:00
|
|
|
|
frame_object *frame_obj = (frame_object *) obj;
|
2022-07-25 14:06:35 -03:00
|
|
|
|
frame_info_ptr frame;
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
|
|
|
|
|
frame = frame_find_by_id (frame_obj->frame_id);
|
|
|
|
|
|
if (frame == NULL)
|
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
|
|
return frame;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* Called by the Python interpreter to obtain string representation
|
|
|
|
|
|
of the object. */
|
|
|
|
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
|
|
frapy_str (PyObject *self)
|
|
|
|
|
|
{
|
2021-05-08 15:43:56 +01:00
|
|
|
|
const frame_id &fid = ((frame_object *) self)->frame_id;
|
2022-03-21 10:07:41 -04:00
|
|
|
|
return PyUnicode_FromString (fid.to_string ().c_str ());
|
2009-03-30 19:54:33 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
2024-01-04 10:57:40 +00:00
|
|
|
|
/* Implement repr() for gdb.Frame. */
|
|
|
|
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
|
|
frapy_repr (PyObject *self)
|
|
|
|
|
|
{
|
|
|
|
|
|
frame_object *frame_obj = (frame_object *) self;
|
|
|
|
|
|
frame_info_ptr f_info = frame_find_by_id (frame_obj->frame_id);
|
|
|
|
|
|
if (f_info == nullptr)
|
|
|
|
|
|
return gdb_py_invalid_object_repr (self);
|
|
|
|
|
|
|
|
|
|
|
|
const frame_id &fid = frame_obj->frame_id;
|
|
|
|
|
|
return PyUnicode_FromFormat ("<%s level=%d frame-id=%s>",
|
2026-05-26 11:46:29 +01:00
|
|
|
|
gdbpy_py_obj_tp_name (self).c_str (),
|
2024-01-04 10:57:40 +00:00
|
|
|
|
frame_relative_level (f_info),
|
|
|
|
|
|
fid.to_string ().c_str ());
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2009-03-30 19:54:33 +00:00
|
|
|
|
/* Implementation of gdb.Frame.is_valid (self) -> Boolean.
|
|
|
|
|
|
Returns True if the frame corresponding to the frame_id of this
|
|
|
|
|
|
object still exists in the inferior. */
|
|
|
|
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
|
|
frapy_is_valid (PyObject *self, PyObject *args)
|
|
|
|
|
|
{
|
2022-07-25 14:06:35 -03:00
|
|
|
|
frame_info_ptr frame = NULL;
|
2011-10-27 09:14:27 +00:00
|
|
|
|
|
2019-04-03 16:02:42 -06:00
|
|
|
|
try
|
2011-10-27 09:14:27 +00:00
|
|
|
|
{
|
2011-12-23 17:06:16 +00:00
|
|
|
|
frame = frame_object_to_frame_info (self);
|
2011-10-27 09:14:27 +00:00
|
|
|
|
}
|
2019-04-03 15:59:07 -06:00
|
|
|
|
catch (const gdb_exception &except)
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
{
|
2024-09-24 13:06:32 +02:00
|
|
|
|
return gdbpy_handle_gdb_exception (nullptr, except);
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
}
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
|
|
|
|
|
if (frame == NULL)
|
2026-05-15 21:38:12 +02:00
|
|
|
|
return py_false ().release ();
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
2026-05-15 21:38:12 +02:00
|
|
|
|
return py_true ().release ();
|
2009-03-30 19:54:33 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* Implementation of gdb.Frame.name (self) -> String.
|
|
|
|
|
|
Returns the name of the function corresponding to this frame. */
|
|
|
|
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
|
|
frapy_name (PyObject *self, PyObject *args)
|
|
|
|
|
|
{
|
2022-07-25 14:06:35 -03:00
|
|
|
|
frame_info_ptr frame;
|
2017-09-09 10:14:52 -06:00
|
|
|
|
gdb::unique_xmalloc_ptr<char> name;
|
2009-03-30 19:54:33 +00:00
|
|
|
|
enum language lang;
|
|
|
|
|
|
PyObject *result;
|
|
|
|
|
|
|
2019-04-03 16:02:42 -06:00
|
|
|
|
try
|
2009-03-30 19:54:33 +00:00
|
|
|
|
{
|
2011-12-23 17:06:16 +00:00
|
|
|
|
FRAPY_REQUIRE_VALID (self, frame);
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
2017-09-09 10:14:52 -06:00
|
|
|
|
name = find_frame_funname (frame, &lang, NULL);
|
2009-03-30 19:54:33 +00:00
|
|
|
|
}
|
2019-04-03 15:59:07 -06:00
|
|
|
|
catch (const gdb_exception &except)
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
{
|
2024-09-24 13:06:32 +02:00
|
|
|
|
return gdbpy_handle_gdb_exception (nullptr, except);
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
}
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
|
|
|
|
|
if (name)
|
2013-05-22 21:16:18 +00:00
|
|
|
|
{
|
2017-09-09 10:14:52 -06:00
|
|
|
|
result = PyUnicode_Decode (name.get (), strlen (name.get ()),
|
|
|
|
|
|
host_charset (), NULL);
|
2013-05-22 21:16:18 +00:00
|
|
|
|
}
|
2009-03-30 19:54:33 +00:00
|
|
|
|
else
|
|
|
|
|
|
{
|
2026-05-15 21:38:12 +02:00
|
|
|
|
result = py_none ().release ();
|
2009-03-30 19:54:33 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
return result;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* Implementation of gdb.Frame.type (self) -> Integer.
|
|
|
|
|
|
Returns the frame type, namely one of the gdb.*_FRAME constants. */
|
|
|
|
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
|
|
frapy_type (PyObject *self, PyObject *args)
|
|
|
|
|
|
{
|
2022-07-25 14:06:35 -03:00
|
|
|
|
frame_info_ptr frame;
|
2009-03-30 19:54:33 +00:00
|
|
|
|
enum frame_type type = NORMAL_FRAME;/* Initialize to appease gcc warning. */
|
|
|
|
|
|
|
2019-04-03 16:02:42 -06:00
|
|
|
|
try
|
2009-03-30 19:54:33 +00:00
|
|
|
|
{
|
2011-12-23 17:06:16 +00:00
|
|
|
|
FRAPY_REQUIRE_VALID (self, frame);
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
|
|
|
|
|
type = get_frame_type (frame);
|
|
|
|
|
|
}
|
2019-04-03 15:59:07 -06:00
|
|
|
|
catch (const gdb_exception &except)
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
{
|
2024-09-24 13:06:32 +02:00
|
|
|
|
return gdbpy_handle_gdb_exception (nullptr, except);
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
}
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
2020-09-15 11:08:56 -06:00
|
|
|
|
return gdb_py_object_from_longest (type).release ();
|
2009-03-30 19:54:33 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
2013-01-23 19:59:13 +00:00
|
|
|
|
/* Implementation of gdb.Frame.architecture (self) -> gdb.Architecture.
|
|
|
|
|
|
Returns the frame's architecture as a gdb.Architecture object. */
|
|
|
|
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
|
|
frapy_arch (PyObject *self, PyObject *args)
|
|
|
|
|
|
{
|
2022-07-25 14:06:35 -03:00
|
|
|
|
frame_info_ptr frame = NULL; /* Initialize to appease gcc warning. */
|
2013-01-23 19:59:13 +00:00
|
|
|
|
frame_object *obj = (frame_object *) self;
|
|
|
|
|
|
|
2019-04-03 16:02:42 -06:00
|
|
|
|
try
|
2013-01-23 19:59:13 +00:00
|
|
|
|
{
|
|
|
|
|
|
FRAPY_REQUIRE_VALID (self, frame);
|
|
|
|
|
|
}
|
2019-04-03 15:59:07 -06:00
|
|
|
|
catch (const gdb_exception &except)
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
{
|
2024-09-24 13:06:32 +02:00
|
|
|
|
return gdbpy_handle_gdb_exception (nullptr, except);
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
}
|
2013-01-23 19:59:13 +00:00
|
|
|
|
|
2026-02-20 13:20:56 -07:00
|
|
|
|
return gdbarch_to_arch_object (obj->gdbarch).release ();
|
2013-01-23 19:59:13 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
2009-03-30 19:54:33 +00:00
|
|
|
|
/* Implementation of gdb.Frame.unwind_stop_reason (self) -> Integer.
|
|
|
|
|
|
Returns one of the gdb.FRAME_UNWIND_* constants. */
|
|
|
|
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
|
|
frapy_unwind_stop_reason (PyObject *self, PyObject *args)
|
|
|
|
|
|
{
|
2022-07-25 14:06:35 -03:00
|
|
|
|
frame_info_ptr frame = NULL; /* Initialize to appease gcc warning. */
|
2009-03-30 19:54:33 +00:00
|
|
|
|
enum unwind_stop_reason stop_reason;
|
|
|
|
|
|
|
2019-04-03 16:02:42 -06:00
|
|
|
|
try
|
2009-03-30 19:54:33 +00:00
|
|
|
|
{
|
2011-12-23 17:06:16 +00:00
|
|
|
|
FRAPY_REQUIRE_VALID (self, frame);
|
2009-03-30 19:54:33 +00:00
|
|
|
|
}
|
2019-04-03 15:59:07 -06:00
|
|
|
|
catch (const gdb_exception &except)
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
{
|
2024-09-24 13:06:32 +02:00
|
|
|
|
return gdbpy_handle_gdb_exception (nullptr, except);
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
}
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
|
|
|
|
|
stop_reason = get_frame_unwind_stop_reason (frame);
|
|
|
|
|
|
|
2020-09-15 11:08:56 -06:00
|
|
|
|
return gdb_py_object_from_longest (stop_reason).release ();
|
2009-03-30 19:54:33 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* Implementation of gdb.Frame.pc (self) -> Long.
|
|
|
|
|
|
Returns the frame's resume address. */
|
|
|
|
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
|
|
frapy_pc (PyObject *self, PyObject *args)
|
|
|
|
|
|
{
|
|
|
|
|
|
CORE_ADDR pc = 0; /* Initialize to appease gcc warning. */
|
2022-07-25 14:06:35 -03:00
|
|
|
|
frame_info_ptr frame;
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
2019-04-03 16:02:42 -06:00
|
|
|
|
try
|
2009-03-30 19:54:33 +00:00
|
|
|
|
{
|
2011-12-23 17:06:16 +00:00
|
|
|
|
FRAPY_REQUIRE_VALID (self, frame);
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
|
|
|
|
|
pc = get_frame_pc (frame);
|
|
|
|
|
|
}
|
2019-04-03 15:59:07 -06:00
|
|
|
|
catch (const gdb_exception &except)
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
{
|
2024-09-24 13:06:32 +02:00
|
|
|
|
return gdbpy_handle_gdb_exception (nullptr, except);
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
}
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
2020-09-15 11:08:56 -06:00
|
|
|
|
return gdb_py_object_from_ulongest (pc).release ();
|
2009-03-30 19:54:33 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
2014-09-03 16:34:47 -07:00
|
|
|
|
/* Implementation of gdb.Frame.read_register (self, register) -> gdb.Value.
|
|
|
|
|
|
Returns the value of a register in this frame. */
|
|
|
|
|
|
|
|
|
|
|
|
static PyObject *
|
2023-03-30 10:40:41 +01:00
|
|
|
|
frapy_read_register (PyObject *self, PyObject *args, PyObject *kw)
|
2014-09-03 16:34:47 -07:00
|
|
|
|
{
|
gdb/python: make more use of RegisterDescriptors
This commit unifies all of the Python register lookup code (used by
Frame.read_register, PendingFrame.read_register, and
gdb.UnwindInfo.add_saved_register), and adds support for using a
gdb.RegisterDescriptor for register lookup.
Currently the register unwind code (PendingFrame and UnwindInfo) allow
registers to be looked up either by name, or by GDB's internal
number. I suspect the number was added for performance reasons, when
unwinding we don't want to repeatedly map from name to number for
every unwind. However, this kind-of sucks, it means Python scripts
could include GDB's internal register numbers, and if we ever change
this numbering in the future users scripts will break in unexpected
ways.
Meanwhile, the Frame.read_register method only supports accessing
registers using a string, the register name.
This commit unifies all of the register to register-number lookup code
in our Python bindings, and adds a third choice into the mix, the use
of gdb.RegisterDescriptor.
The register descriptors can be looked up by name, but once looked up,
they contain GDB's register number, and so provide all of the
performance benefits of using a register number directly. However, as
they are looked up by name we are no longer tightly binding the Python
API to GDB's internal numbering scheme.
As we may already have scripts in the wild that are using the register
numbers directly I have kept support for this in the API, but I have
listed this method last in the manual, and I have tried to stress that
this is NOT a good method to use and that users should use either a
string or register descriptor approach.
After this commit all existing Python code should function as before,
but users now have new options for how to identify registers.
gdb/ChangeLog:
* python/py-frame.c: Remove 'user-regs.h' include.
(frapy_read_register): Rewrite to make use of
gdbpy_parse_register_id.
* python/py-registers.c (gdbpy_parse_register_id): New function,
moved here from python/py-unwind.c. Updated the return type, and
also accepts register descriptor objects.
* python/py-unwind.c: Remove 'user-regs.h' include.
(pyuw_parse_register_id): Moved to python/py-registers.c.
(unwind_infopy_add_saved_register): Update to use
gdbpy_parse_register_id.
(pending_framepy_read_register): Likewise.
* python/python-internal.h (gdbpy_parse_register_id): Declare.
gdb/testsuite/ChangeLog:
* gdb.python/py-unwind.py: Update to make use of a register
descriptor.
gdb/doc/ChangeLog:
* python.texi (Unwinding Frames in Python): Update descriptions
for PendingFrame.read_register and
gdb.UnwindInfo.add_saved_register.
(Frames In Python): Update description of Frame.read_register.
2020-07-22 12:13:11 +01:00
|
|
|
|
PyObject *pyo_reg_id;
|
2026-02-20 13:02:00 -07:00
|
|
|
|
gdbpy_ref<> result;
|
2014-09-03 16:34:47 -07:00
|
|
|
|
|
2023-03-30 10:40:41 +01:00
|
|
|
|
static const char *keywords[] = { "register", nullptr };
|
|
|
|
|
|
if (!gdb_PyArg_ParseTupleAndKeywords (args, kw, "O", keywords, &pyo_reg_id))
|
|
|
|
|
|
return nullptr;
|
|
|
|
|
|
|
2019-04-03 16:02:42 -06:00
|
|
|
|
try
|
2014-09-03 16:34:47 -07:00
|
|
|
|
{
|
Fix value chain use-after-free
Hannes filed a bug showing a crash, where a pretty-printer written in
Python could cause a use-after-free. He sent a patch, but I thought a
different approach was needed.
In a much earlier patch (see bug #12533), we changed the Python code
to release new values from the value chain when constructing a
gdb.Value. The rationale for this is that if you write a command that
does a lot of computations in a loop, all the values will be kept live
by the value chain, resulting in gdb using a large amount of memory.
However, suppose a value is passed to Python from some code in gdb
that needs to use the value after the call into Python. In this
scenario, value_to_value_object will still release the value -- and
because gdb code doesn't generally keep strong references to values (a
consequence of the ancient decision to use the value chain to avoid
memory management), this will result in a use-after-free.
This scenario can happen, as it turns out, when a value is passed to
Python for pretty-printing. Now, normally this route boxes the value
via value_to_value_object_no_release, avoiding the problematic release
from the value chain. However, if you then call Value.cast, the
underlying value API might return the same value, when is then
released from the chain.
This patch fixes the problem by changing how value boxing is done.
value_to_value_object no longer removes a value from the chain.
Instead, every spot in gdb that might construct new values uses a
scoped_value_mark to ensure that the requirements of bug #12533 are
met. And, because incoming values aren't ever released from the chain
(the Value.cast one comes earlier on the chain than the
scoped_value_mark), the bug can no longer occur. (Note that many
spots in the Python layer already take this approach, so not many
places needed to be touched.)
In the future I think we should replace the use of raw "value *" with
value_ref_ptr pretty much everywhere. This will ensure lifetime
safety throughout gdb.
The test case in this patch comes from Hannes' original patch. I only
made a trivial ("require") change to it. However, while this fails
for him, I can't make it fail on this machine; nevertheless, he tried
my patch and reported the bug as being fixed.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30044
2023-02-08 13:59:36 -07:00
|
|
|
|
scoped_value_mark free_values;
|
2022-07-25 14:06:35 -03:00
|
|
|
|
frame_info_ptr frame;
|
2014-09-03 16:34:47 -07:00
|
|
|
|
int regnum;
|
|
|
|
|
|
|
|
|
|
|
|
FRAPY_REQUIRE_VALID (self, frame);
|
|
|
|
|
|
|
gdb/python: make more use of RegisterDescriptors
This commit unifies all of the Python register lookup code (used by
Frame.read_register, PendingFrame.read_register, and
gdb.UnwindInfo.add_saved_register), and adds support for using a
gdb.RegisterDescriptor for register lookup.
Currently the register unwind code (PendingFrame and UnwindInfo) allow
registers to be looked up either by name, or by GDB's internal
number. I suspect the number was added for performance reasons, when
unwinding we don't want to repeatedly map from name to number for
every unwind. However, this kind-of sucks, it means Python scripts
could include GDB's internal register numbers, and if we ever change
this numbering in the future users scripts will break in unexpected
ways.
Meanwhile, the Frame.read_register method only supports accessing
registers using a string, the register name.
This commit unifies all of the register to register-number lookup code
in our Python bindings, and adds a third choice into the mix, the use
of gdb.RegisterDescriptor.
The register descriptors can be looked up by name, but once looked up,
they contain GDB's register number, and so provide all of the
performance benefits of using a register number directly. However, as
they are looked up by name we are no longer tightly binding the Python
API to GDB's internal numbering scheme.
As we may already have scripts in the wild that are using the register
numbers directly I have kept support for this in the API, but I have
listed this method last in the manual, and I have tried to stress that
this is NOT a good method to use and that users should use either a
string or register descriptor approach.
After this commit all existing Python code should function as before,
but users now have new options for how to identify registers.
gdb/ChangeLog:
* python/py-frame.c: Remove 'user-regs.h' include.
(frapy_read_register): Rewrite to make use of
gdbpy_parse_register_id.
* python/py-registers.c (gdbpy_parse_register_id): New function,
moved here from python/py-unwind.c. Updated the return type, and
also accepts register descriptor objects.
* python/py-unwind.c: Remove 'user-regs.h' include.
(pyuw_parse_register_id): Moved to python/py-registers.c.
(unwind_infopy_add_saved_register): Update to use
gdbpy_parse_register_id.
(pending_framepy_read_register): Likewise.
* python/python-internal.h (gdbpy_parse_register_id): Declare.
gdb/testsuite/ChangeLog:
* gdb.python/py-unwind.py: Update to make use of a register
descriptor.
gdb/doc/ChangeLog:
* python.texi (Unwinding Frames in Python): Update descriptions
for PendingFrame.read_register and
gdb.UnwindInfo.add_saved_register.
(Frames In Python): Update description of Frame.read_register.
2020-07-22 12:13:11 +01:00
|
|
|
|
if (!gdbpy_parse_register_id (get_frame_arch (frame), pyo_reg_id,
|
|
|
|
|
|
®num))
|
2022-04-27 15:22:56 -06:00
|
|
|
|
return nullptr;
|
gdb/python: make more use of RegisterDescriptors
This commit unifies all of the Python register lookup code (used by
Frame.read_register, PendingFrame.read_register, and
gdb.UnwindInfo.add_saved_register), and adds support for using a
gdb.RegisterDescriptor for register lookup.
Currently the register unwind code (PendingFrame and UnwindInfo) allow
registers to be looked up either by name, or by GDB's internal
number. I suspect the number was added for performance reasons, when
unwinding we don't want to repeatedly map from name to number for
every unwind. However, this kind-of sucks, it means Python scripts
could include GDB's internal register numbers, and if we ever change
this numbering in the future users scripts will break in unexpected
ways.
Meanwhile, the Frame.read_register method only supports accessing
registers using a string, the register name.
This commit unifies all of the register to register-number lookup code
in our Python bindings, and adds a third choice into the mix, the use
of gdb.RegisterDescriptor.
The register descriptors can be looked up by name, but once looked up,
they contain GDB's register number, and so provide all of the
performance benefits of using a register number directly. However, as
they are looked up by name we are no longer tightly binding the Python
API to GDB's internal numbering scheme.
As we may already have scripts in the wild that are using the register
numbers directly I have kept support for this in the API, but I have
listed this method last in the manual, and I have tried to stress that
this is NOT a good method to use and that users should use either a
string or register descriptor approach.
After this commit all existing Python code should function as before,
but users now have new options for how to identify registers.
gdb/ChangeLog:
* python/py-frame.c: Remove 'user-regs.h' include.
(frapy_read_register): Rewrite to make use of
gdbpy_parse_register_id.
* python/py-registers.c (gdbpy_parse_register_id): New function,
moved here from python/py-unwind.c. Updated the return type, and
also accepts register descriptor objects.
* python/py-unwind.c: Remove 'user-regs.h' include.
(pyuw_parse_register_id): Moved to python/py-registers.c.
(unwind_infopy_add_saved_register): Update to use
gdbpy_parse_register_id.
(pending_framepy_read_register): Likewise.
* python/python-internal.h (gdbpy_parse_register_id): Declare.
gdb/testsuite/ChangeLog:
* gdb.python/py-unwind.py: Update to make use of a register
descriptor.
gdb/doc/ChangeLog:
* python.texi (Unwinding Frames in Python): Update descriptions
for PendingFrame.read_register and
gdb.UnwindInfo.add_saved_register.
(Frames In Python): Update description of Frame.read_register.
2020-07-22 12:13:11 +01:00
|
|
|
|
|
|
|
|
|
|
gdb_assert (regnum >= 0);
|
2023-12-01 11:27:21 -05:00
|
|
|
|
value *val
|
|
|
|
|
|
= value_of_register (regnum, get_next_frame_sentinel_okay (frame));
|
2014-09-03 16:34:47 -07:00
|
|
|
|
|
|
|
|
|
|
if (val == NULL)
|
gdb, gdbserver, gdbsupport: fix leading space vs tabs issues
Many spots incorrectly use only spaces for indentation (for example,
there are a lot of spots in ada-lang.c). I've always found it awkward
when I needed to edit one of these spots: do I keep the original wrong
indentation, or do I fix it? What if the lines around it are also
wrong, do I fix them too? I probably don't want to fix them in the same
patch, to avoid adding noise to my patch.
So I propose to fix as much as possible once and for all (hopefully).
One typical counter argument for this is that it makes code archeology
more difficult, because git-blame will show this commit as the last
change for these lines. My counter counter argument is: when
git-blaming, you often need to do "blame the file at the parent commit"
anyway, to go past some other refactor that touched the line you are
interested in, but is not the change you are looking for. So you
already need a somewhat efficient way to do this.
Using some interactive tool, rather than plain git-blame, makes this
trivial. For example, I use "tig blame <file>", where going back past
the commit that changed the currently selected line is one keystroke.
It looks like Magit in Emacs does it too (though I've never used it).
Web viewers of Github and Gitlab do it too. My point is that it won't
really make archeology more difficult.
The other typical counter argument is that it will cause conflicts with
existing patches. That's true... but it's a one time cost, and those
are not conflicts that are difficult to resolve. I have also tried "git
rebase --ignore-whitespace", it seems to work well. Although that will
re-introduce the faulty indentation, so one needs to take care of fixing
the indentation in the patch after that (which is easy).
gdb/ChangeLog:
* aarch64-linux-tdep.c: Fix indentation.
* aarch64-ravenscar-thread.c: Fix indentation.
* aarch64-tdep.c: Fix indentation.
* aarch64-tdep.h: Fix indentation.
* ada-lang.c: Fix indentation.
* ada-lang.h: Fix indentation.
* ada-tasks.c: Fix indentation.
* ada-typeprint.c: Fix indentation.
* ada-valprint.c: Fix indentation.
* ada-varobj.c: Fix indentation.
* addrmap.c: Fix indentation.
* addrmap.h: Fix indentation.
* agent.c: Fix indentation.
* aix-thread.c: Fix indentation.
* alpha-bsd-nat.c: Fix indentation.
* alpha-linux-tdep.c: Fix indentation.
* alpha-mdebug-tdep.c: Fix indentation.
* alpha-nbsd-tdep.c: Fix indentation.
* alpha-obsd-tdep.c: Fix indentation.
* alpha-tdep.c: Fix indentation.
* amd64-bsd-nat.c: Fix indentation.
* amd64-darwin-tdep.c: Fix indentation.
* amd64-linux-nat.c: Fix indentation.
* amd64-linux-tdep.c: Fix indentation.
* amd64-nat.c: Fix indentation.
* amd64-obsd-tdep.c: Fix indentation.
* amd64-tdep.c: Fix indentation.
* amd64-windows-tdep.c: Fix indentation.
* annotate.c: Fix indentation.
* arc-tdep.c: Fix indentation.
* arch-utils.c: Fix indentation.
* arch/arm-get-next-pcs.c: Fix indentation.
* arch/arm.c: Fix indentation.
* arm-linux-nat.c: Fix indentation.
* arm-linux-tdep.c: Fix indentation.
* arm-nbsd-tdep.c: Fix indentation.
* arm-pikeos-tdep.c: Fix indentation.
* arm-tdep.c: Fix indentation.
* arm-tdep.h: Fix indentation.
* arm-wince-tdep.c: Fix indentation.
* auto-load.c: Fix indentation.
* auxv.c: Fix indentation.
* avr-tdep.c: Fix indentation.
* ax-gdb.c: Fix indentation.
* ax-general.c: Fix indentation.
* bfin-linux-tdep.c: Fix indentation.
* block.c: Fix indentation.
* block.h: Fix indentation.
* blockframe.c: Fix indentation.
* bpf-tdep.c: Fix indentation.
* break-catch-sig.c: Fix indentation.
* break-catch-syscall.c: Fix indentation.
* break-catch-throw.c: Fix indentation.
* breakpoint.c: Fix indentation.
* breakpoint.h: Fix indentation.
* bsd-uthread.c: Fix indentation.
* btrace.c: Fix indentation.
* build-id.c: Fix indentation.
* buildsym-legacy.h: Fix indentation.
* buildsym.c: Fix indentation.
* c-typeprint.c: Fix indentation.
* c-valprint.c: Fix indentation.
* c-varobj.c: Fix indentation.
* charset.c: Fix indentation.
* cli/cli-cmds.c: Fix indentation.
* cli/cli-decode.c: Fix indentation.
* cli/cli-decode.h: Fix indentation.
* cli/cli-script.c: Fix indentation.
* cli/cli-setshow.c: Fix indentation.
* coff-pe-read.c: Fix indentation.
* coffread.c: Fix indentation.
* compile/compile-cplus-types.c: Fix indentation.
* compile/compile-object-load.c: Fix indentation.
* compile/compile-object-run.c: Fix indentation.
* completer.c: Fix indentation.
* corefile.c: Fix indentation.
* corelow.c: Fix indentation.
* cp-abi.h: Fix indentation.
* cp-namespace.c: Fix indentation.
* cp-support.c: Fix indentation.
* cp-valprint.c: Fix indentation.
* cris-linux-tdep.c: Fix indentation.
* cris-tdep.c: Fix indentation.
* darwin-nat-info.c: Fix indentation.
* darwin-nat.c: Fix indentation.
* darwin-nat.h: Fix indentation.
* dbxread.c: Fix indentation.
* dcache.c: Fix indentation.
* disasm.c: Fix indentation.
* dtrace-probe.c: Fix indentation.
* dwarf2/abbrev.c: Fix indentation.
* dwarf2/attribute.c: Fix indentation.
* dwarf2/expr.c: Fix indentation.
* dwarf2/frame.c: Fix indentation.
* dwarf2/index-cache.c: Fix indentation.
* dwarf2/index-write.c: Fix indentation.
* dwarf2/line-header.c: Fix indentation.
* dwarf2/loc.c: Fix indentation.
* dwarf2/macro.c: Fix indentation.
* dwarf2/read.c: Fix indentation.
* dwarf2/read.h: Fix indentation.
* elfread.c: Fix indentation.
* eval.c: Fix indentation.
* event-top.c: Fix indentation.
* exec.c: Fix indentation.
* exec.h: Fix indentation.
* expprint.c: Fix indentation.
* f-lang.c: Fix indentation.
* f-typeprint.c: Fix indentation.
* f-valprint.c: Fix indentation.
* fbsd-nat.c: Fix indentation.
* fbsd-tdep.c: Fix indentation.
* findvar.c: Fix indentation.
* fork-child.c: Fix indentation.
* frame-unwind.c: Fix indentation.
* frame-unwind.h: Fix indentation.
* frame.c: Fix indentation.
* frv-linux-tdep.c: Fix indentation.
* frv-tdep.c: Fix indentation.
* frv-tdep.h: Fix indentation.
* ft32-tdep.c: Fix indentation.
* gcore.c: Fix indentation.
* gdb_bfd.c: Fix indentation.
* gdbarch.sh: Fix indentation.
* gdbarch.c: Re-generate
* gdbarch.h: Re-generate.
* gdbcore.h: Fix indentation.
* gdbthread.h: Fix indentation.
* gdbtypes.c: Fix indentation.
* gdbtypes.h: Fix indentation.
* glibc-tdep.c: Fix indentation.
* gnu-nat.c: Fix indentation.
* gnu-nat.h: Fix indentation.
* gnu-v2-abi.c: Fix indentation.
* gnu-v3-abi.c: Fix indentation.
* go32-nat.c: Fix indentation.
* guile/guile-internal.h: Fix indentation.
* guile/scm-cmd.c: Fix indentation.
* guile/scm-frame.c: Fix indentation.
* guile/scm-iterator.c: Fix indentation.
* guile/scm-math.c: Fix indentation.
* guile/scm-ports.c: Fix indentation.
* guile/scm-pretty-print.c: Fix indentation.
* guile/scm-value.c: Fix indentation.
* h8300-tdep.c: Fix indentation.
* hppa-linux-nat.c: Fix indentation.
* hppa-linux-tdep.c: Fix indentation.
* hppa-nbsd-nat.c: Fix indentation.
* hppa-nbsd-tdep.c: Fix indentation.
* hppa-obsd-nat.c: Fix indentation.
* hppa-tdep.c: Fix indentation.
* hppa-tdep.h: Fix indentation.
* i386-bsd-nat.c: Fix indentation.
* i386-darwin-nat.c: Fix indentation.
* i386-darwin-tdep.c: Fix indentation.
* i386-dicos-tdep.c: Fix indentation.
* i386-gnu-nat.c: Fix indentation.
* i386-linux-nat.c: Fix indentation.
* i386-linux-tdep.c: Fix indentation.
* i386-nto-tdep.c: Fix indentation.
* i386-obsd-tdep.c: Fix indentation.
* i386-sol2-nat.c: Fix indentation.
* i386-tdep.c: Fix indentation.
* i386-tdep.h: Fix indentation.
* i386-windows-tdep.c: Fix indentation.
* i387-tdep.c: Fix indentation.
* i387-tdep.h: Fix indentation.
* ia64-libunwind-tdep.c: Fix indentation.
* ia64-libunwind-tdep.h: Fix indentation.
* ia64-linux-nat.c: Fix indentation.
* ia64-linux-tdep.c: Fix indentation.
* ia64-tdep.c: Fix indentation.
* ia64-tdep.h: Fix indentation.
* ia64-vms-tdep.c: Fix indentation.
* infcall.c: Fix indentation.
* infcmd.c: Fix indentation.
* inferior.c: Fix indentation.
* infrun.c: Fix indentation.
* iq2000-tdep.c: Fix indentation.
* language.c: Fix indentation.
* linespec.c: Fix indentation.
* linux-fork.c: Fix indentation.
* linux-nat.c: Fix indentation.
* linux-tdep.c: Fix indentation.
* linux-thread-db.c: Fix indentation.
* lm32-tdep.c: Fix indentation.
* m2-lang.c: Fix indentation.
* m2-typeprint.c: Fix indentation.
* m2-valprint.c: Fix indentation.
* m32c-tdep.c: Fix indentation.
* m32r-linux-tdep.c: Fix indentation.
* m32r-tdep.c: Fix indentation.
* m68hc11-tdep.c: Fix indentation.
* m68k-bsd-nat.c: Fix indentation.
* m68k-linux-nat.c: Fix indentation.
* m68k-linux-tdep.c: Fix indentation.
* m68k-tdep.c: Fix indentation.
* machoread.c: Fix indentation.
* macrocmd.c: Fix indentation.
* macroexp.c: Fix indentation.
* macroscope.c: Fix indentation.
* macrotab.c: Fix indentation.
* macrotab.h: Fix indentation.
* main.c: Fix indentation.
* mdebugread.c: Fix indentation.
* mep-tdep.c: Fix indentation.
* mi/mi-cmd-catch.c: Fix indentation.
* mi/mi-cmd-disas.c: Fix indentation.
* mi/mi-cmd-env.c: Fix indentation.
* mi/mi-cmd-stack.c: Fix indentation.
* mi/mi-cmd-var.c: Fix indentation.
* mi/mi-cmds.c: Fix indentation.
* mi/mi-main.c: Fix indentation.
* mi/mi-parse.c: Fix indentation.
* microblaze-tdep.c: Fix indentation.
* minidebug.c: Fix indentation.
* minsyms.c: Fix indentation.
* mips-linux-nat.c: Fix indentation.
* mips-linux-tdep.c: Fix indentation.
* mips-nbsd-tdep.c: Fix indentation.
* mips-tdep.c: Fix indentation.
* mn10300-linux-tdep.c: Fix indentation.
* mn10300-tdep.c: Fix indentation.
* moxie-tdep.c: Fix indentation.
* msp430-tdep.c: Fix indentation.
* namespace.h: Fix indentation.
* nat/fork-inferior.c: Fix indentation.
* nat/gdb_ptrace.h: Fix indentation.
* nat/linux-namespaces.c: Fix indentation.
* nat/linux-osdata.c: Fix indentation.
* nat/netbsd-nat.c: Fix indentation.
* nat/x86-dregs.c: Fix indentation.
* nbsd-nat.c: Fix indentation.
* nbsd-tdep.c: Fix indentation.
* nios2-linux-tdep.c: Fix indentation.
* nios2-tdep.c: Fix indentation.
* nto-procfs.c: Fix indentation.
* nto-tdep.c: Fix indentation.
* objfiles.c: Fix indentation.
* objfiles.h: Fix indentation.
* opencl-lang.c: Fix indentation.
* or1k-tdep.c: Fix indentation.
* osabi.c: Fix indentation.
* osabi.h: Fix indentation.
* osdata.c: Fix indentation.
* p-lang.c: Fix indentation.
* p-typeprint.c: Fix indentation.
* p-valprint.c: Fix indentation.
* parse.c: Fix indentation.
* ppc-linux-nat.c: Fix indentation.
* ppc-linux-tdep.c: Fix indentation.
* ppc-nbsd-nat.c: Fix indentation.
* ppc-nbsd-tdep.c: Fix indentation.
* ppc-obsd-nat.c: Fix indentation.
* ppc-ravenscar-thread.c: Fix indentation.
* ppc-sysv-tdep.c: Fix indentation.
* ppc64-tdep.c: Fix indentation.
* printcmd.c: Fix indentation.
* proc-api.c: Fix indentation.
* producer.c: Fix indentation.
* producer.h: Fix indentation.
* prologue-value.c: Fix indentation.
* prologue-value.h: Fix indentation.
* psymtab.c: Fix indentation.
* python/py-arch.c: Fix indentation.
* python/py-bpevent.c: Fix indentation.
* python/py-event.c: Fix indentation.
* python/py-event.h: Fix indentation.
* python/py-finishbreakpoint.c: Fix indentation.
* python/py-frame.c: Fix indentation.
* python/py-framefilter.c: Fix indentation.
* python/py-inferior.c: Fix indentation.
* python/py-infthread.c: Fix indentation.
* python/py-objfile.c: Fix indentation.
* python/py-prettyprint.c: Fix indentation.
* python/py-registers.c: Fix indentation.
* python/py-signalevent.c: Fix indentation.
* python/py-stopevent.c: Fix indentation.
* python/py-stopevent.h: Fix indentation.
* python/py-threadevent.c: Fix indentation.
* python/py-tui.c: Fix indentation.
* python/py-unwind.c: Fix indentation.
* python/py-value.c: Fix indentation.
* python/py-xmethods.c: Fix indentation.
* python/python-internal.h: Fix indentation.
* python/python.c: Fix indentation.
* ravenscar-thread.c: Fix indentation.
* record-btrace.c: Fix indentation.
* record-full.c: Fix indentation.
* record.c: Fix indentation.
* reggroups.c: Fix indentation.
* regset.h: Fix indentation.
* remote-fileio.c: Fix indentation.
* remote.c: Fix indentation.
* reverse.c: Fix indentation.
* riscv-linux-tdep.c: Fix indentation.
* riscv-ravenscar-thread.c: Fix indentation.
* riscv-tdep.c: Fix indentation.
* rl78-tdep.c: Fix indentation.
* rs6000-aix-tdep.c: Fix indentation.
* rs6000-lynx178-tdep.c: Fix indentation.
* rs6000-nat.c: Fix indentation.
* rs6000-tdep.c: Fix indentation.
* rust-lang.c: Fix indentation.
* rx-tdep.c: Fix indentation.
* s12z-tdep.c: Fix indentation.
* s390-linux-tdep.c: Fix indentation.
* score-tdep.c: Fix indentation.
* ser-base.c: Fix indentation.
* ser-mingw.c: Fix indentation.
* ser-uds.c: Fix indentation.
* ser-unix.c: Fix indentation.
* serial.c: Fix indentation.
* sh-linux-tdep.c: Fix indentation.
* sh-nbsd-tdep.c: Fix indentation.
* sh-tdep.c: Fix indentation.
* skip.c: Fix indentation.
* sol-thread.c: Fix indentation.
* solib-aix.c: Fix indentation.
* solib-darwin.c: Fix indentation.
* solib-frv.c: Fix indentation.
* solib-svr4.c: Fix indentation.
* solib.c: Fix indentation.
* source.c: Fix indentation.
* sparc-linux-tdep.c: Fix indentation.
* sparc-nbsd-tdep.c: Fix indentation.
* sparc-obsd-tdep.c: Fix indentation.
* sparc-ravenscar-thread.c: Fix indentation.
* sparc-tdep.c: Fix indentation.
* sparc64-linux-tdep.c: Fix indentation.
* sparc64-nbsd-tdep.c: Fix indentation.
* sparc64-obsd-tdep.c: Fix indentation.
* sparc64-tdep.c: Fix indentation.
* stabsread.c: Fix indentation.
* stack.c: Fix indentation.
* stap-probe.c: Fix indentation.
* stubs/ia64vms-stub.c: Fix indentation.
* stubs/m32r-stub.c: Fix indentation.
* stubs/m68k-stub.c: Fix indentation.
* stubs/sh-stub.c: Fix indentation.
* stubs/sparc-stub.c: Fix indentation.
* symfile-mem.c: Fix indentation.
* symfile.c: Fix indentation.
* symfile.h: Fix indentation.
* symmisc.c: Fix indentation.
* symtab.c: Fix indentation.
* symtab.h: Fix indentation.
* target-float.c: Fix indentation.
* target.c: Fix indentation.
* target.h: Fix indentation.
* tic6x-tdep.c: Fix indentation.
* tilegx-linux-tdep.c: Fix indentation.
* tilegx-tdep.c: Fix indentation.
* top.c: Fix indentation.
* tracefile-tfile.c: Fix indentation.
* tracepoint.c: Fix indentation.
* tui/tui-disasm.c: Fix indentation.
* tui/tui-io.c: Fix indentation.
* tui/tui-regs.c: Fix indentation.
* tui/tui-stack.c: Fix indentation.
* tui/tui-win.c: Fix indentation.
* tui/tui-winsource.c: Fix indentation.
* tui/tui.c: Fix indentation.
* typeprint.c: Fix indentation.
* ui-out.h: Fix indentation.
* unittests/copy_bitwise-selftests.c: Fix indentation.
* unittests/memory-map-selftests.c: Fix indentation.
* utils.c: Fix indentation.
* v850-tdep.c: Fix indentation.
* valarith.c: Fix indentation.
* valops.c: Fix indentation.
* valprint.c: Fix indentation.
* valprint.h: Fix indentation.
* value.c: Fix indentation.
* value.h: Fix indentation.
* varobj.c: Fix indentation.
* vax-tdep.c: Fix indentation.
* windows-nat.c: Fix indentation.
* windows-tdep.c: Fix indentation.
* xcoffread.c: Fix indentation.
* xml-syscall.c: Fix indentation.
* xml-tdesc.c: Fix indentation.
* xstormy16-tdep.c: Fix indentation.
* xtensa-config.c: Fix indentation.
* xtensa-linux-nat.c: Fix indentation.
* xtensa-linux-tdep.c: Fix indentation.
* xtensa-tdep.c: Fix indentation.
gdbserver/ChangeLog:
* ax.cc: Fix indentation.
* dll.cc: Fix indentation.
* inferiors.h: Fix indentation.
* linux-low.cc: Fix indentation.
* linux-nios2-low.cc: Fix indentation.
* linux-ppc-ipa.cc: Fix indentation.
* linux-ppc-low.cc: Fix indentation.
* linux-x86-low.cc: Fix indentation.
* linux-xtensa-low.cc: Fix indentation.
* regcache.cc: Fix indentation.
* server.cc: Fix indentation.
* tracepoint.cc: Fix indentation.
gdbsupport/ChangeLog:
* common-exceptions.h: Fix indentation.
* event-loop.cc: Fix indentation.
* fileio.cc: Fix indentation.
* filestuff.cc: Fix indentation.
* gdb-dlfcn.cc: Fix indentation.
* gdb_string_view.h: Fix indentation.
* job-control.cc: Fix indentation.
* signals.cc: Fix indentation.
Change-Id: I4bad7ae6be0fbe14168b8ebafb98ffe14964a695
2020-11-02 10:26:14 -05:00
|
|
|
|
PyErr_SetString (PyExc_ValueError, _("Can't read register."));
|
Fix value chain use-after-free
Hannes filed a bug showing a crash, where a pretty-printer written in
Python could cause a use-after-free. He sent a patch, but I thought a
different approach was needed.
In a much earlier patch (see bug #12533), we changed the Python code
to release new values from the value chain when constructing a
gdb.Value. The rationale for this is that if you write a command that
does a lot of computations in a loop, all the values will be kept live
by the value chain, resulting in gdb using a large amount of memory.
However, suppose a value is passed to Python from some code in gdb
that needs to use the value after the call into Python. In this
scenario, value_to_value_object will still release the value -- and
because gdb code doesn't generally keep strong references to values (a
consequence of the ancient decision to use the value chain to avoid
memory management), this will result in a use-after-free.
This scenario can happen, as it turns out, when a value is passed to
Python for pretty-printing. Now, normally this route boxes the value
via value_to_value_object_no_release, avoiding the problematic release
from the value chain. However, if you then call Value.cast, the
underlying value API might return the same value, when is then
released from the chain.
This patch fixes the problem by changing how value boxing is done.
value_to_value_object no longer removes a value from the chain.
Instead, every spot in gdb that might construct new values uses a
scoped_value_mark to ensure that the requirements of bug #12533 are
met. And, because incoming values aren't ever released from the chain
(the Value.cast one comes earlier on the chain than the
scoped_value_mark), the bug can no longer occur. (Note that many
spots in the Python layer already take this approach, so not many
places needed to be touched.)
In the future I think we should replace the use of raw "value *" with
value_ref_ptr pretty much everywhere. This will ensure lifetime
safety throughout gdb.
The test case in this patch comes from Hannes' original patch. I only
made a trivial ("require") change to it. However, while this fails
for him, I can't make it fail on this machine; nevertheless, he tried
my patch and reported the bug as being fixed.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30044
2023-02-08 13:59:36 -07:00
|
|
|
|
else
|
|
|
|
|
|
result = value_to_value_object (val);
|
2014-09-03 16:34:47 -07:00
|
|
|
|
}
|
2019-04-03 15:59:07 -06:00
|
|
|
|
catch (const gdb_exception &except)
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
{
|
2024-09-24 13:06:32 +02:00
|
|
|
|
return gdbpy_handle_gdb_exception (nullptr, except);
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
}
|
2014-09-03 16:34:47 -07:00
|
|
|
|
|
2026-02-20 13:02:00 -07:00
|
|
|
|
return result.release ();
|
2014-09-03 16:34:47 -07:00
|
|
|
|
}
|
|
|
|
|
|
|
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
Tom Tromey <tromey@redhat.com>
Thiago Jung Bauermann <bauerman@br.ibm.com>
* python/python.c (_initialize_python): Call
gdbpy_initialize_symtabs, gdbpy_initialize_symbols and
gdbpy_initialize_blocks.
* python/python-internal.h: Declare struct symbol, block and
symtab_and_line. Declare block_object_type and
symbol_object_type
(gdbpy_lookup_symbol gdbpy_block_for_pc)
(symtab_and_line_to_sal_object, symtab_to_symtab_object)
(symbol_to_symbol_object, block_to_block_object)
(gdbpy_initialize_symtabs,gdbpy_initialize_symbols)
(gdbpy_initialize_blocks ): Declare.
* python/py-frame.c (frapy_block, frapy_function, frapy_find_sal)
(frapy_select): Add methods.
(frapy_read_var): Add symbol branch.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-symbol, py-symtab,
py-block.
(SUBDIR_PYTHON_SRCS): Likewise.
(py-symbol.o): New rule.
(py-symtab.o): Likewise.
(py-block.o): Likewise.
* python/py-symbol.c: New file.
* python/py-symtab.c: Likewise.
* python/py-block.c: Likewise.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* Makefile.in: Add py-block and py-symbol.
* gdb.python/py-symbol.exp: New File.
* gdb.python/py-symtab.exp: New File.
* gdb.python/py-block.exp: New File.
* gdb.python/py-symbol.c: New File.
* gdb.python/py-block.c: New File.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Frames In Python): Add block, find_sal, function
and select method descriptions.
(Python API): Add Blocks In Python, Symbols in Python and Symbol
Tables in Python to menu.
(Blocks In Python): New node.
(Symbols In Python): New node.
(Symbol Tables in Python): New node.
2010-02-24 21:18:28 +00:00
|
|
|
|
/* Implementation of gdb.Frame.block (self) -> gdb.Block.
|
|
|
|
|
|
Returns the frame's code block. */
|
|
|
|
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
|
|
frapy_block (PyObject *self, PyObject *args)
|
|
|
|
|
|
{
|
2022-07-25 14:06:35 -03:00
|
|
|
|
frame_info_ptr frame;
|
constify struct block in some places
This makes some spots in gdb, particularly general_symbol_info, use a
"const struct block", then fixes the fallout.
The justification is that, ordinarily, blocks ought to be readonly.
Note though that we can't add "const" in the blockvector due to block
relocation. This can be done once blocks are made independent of the
program space.
2014-06-18 Tom Tromey <tromey@redhat.com>
* varobj.c (varobj_create): Update.
* valops.c (value_of_this): Update.
* tracepoint.c (add_local_symbols, scope_info): Update.
* symtab.h (struct general_symbol_info) <block>: Now const.
* symtab.c (skip_prologue_sal)
(default_make_symbol_completion_list_break_on)
(skip_prologue_using_sal): Update.
* stack.h (iterate_over_block_locals)
(iterate_over_block_local_vars): Update.
* stack.c (print_frame_args): Update.
(iterate_over_block_locals, iterate_over_block_local_vars): Make
parameter const.
(get_selected_block): Make return type const.
* python/py-frame.c (frapy_block): Update.
* python/py-block.c (gdbpy_block_for_pc): Update.
* p-exp.y (%union) <bval>: Now const.
* mi/mi-cmd-stack.c (list_args_or_locals): Update.
* mdebugread.c (mylookup_symbol, parse_procedure): Update.
* m2-exp.y (%union) <bval>: Now const.
* linespec.c (get_current_search_block): Make return type const.
(create_sals_line_offset, find_label_symbols): Update.
* inline-frame.c (inline_frame_sniffer, skip_inline_frames):
Update.
(block_starting_point_at): Make "block" const.
* infrun.c (insert_exception_resume_breakpoint): Make "b" const.
(check_exception_resume): Update.
* guile/scm-frame.c (gdbscm_frame_block): Update.
* guile/scm-block.c (gdbscm_lookup_block): Update.
* frame.h (get_frame_block): Update.
(get_selected_block): Make return type const.
* frame.c (frame_id_inner): Update.
* f-valprint.c (info_common_command_for_block)
(info_common_command): Update.
* dwarf2loc.c (dwarf2_find_location_expression)
(dwarf_expr_frame_base, dwarf2_compile_expr_to_ax)
(locexpr_describe_location_piece): Update.
* c-exp.y (%union) <bval>: Now const.
* breakpoint.c (resolve_sal_pc): Update.
* blockframe.c (get_frame_block):Make return type const.
(get_pc_function_start, get_frame_function, find_pc_sect_function)
(block_innermost_frame): Update.
* block.h (blockvector_for_pc, blockvector_for_pc_sect)
(block_for_pc, block_for_pc_sect): Update.
* block.c (blockvector_for_pc_sect, blockvector_for_pc): Make
'pblock' const.
(block_for_pc_sect, block_for_pc): Make return type const.
* ax-gdb.c (gen_expr): Update.
* alpha-mdebug-tdep.c (find_proc_desc): Update.
* ada-lang.c (ada_read_renaming_var_value): Make 'block' const.
(ada_make_symbol_completion_list, ada_add_exceptions_from_frame)
(ada_read_var_value): Update.
* ada-exp.y (struct name_info) <block>: Now const.
(%union): Likewise.
(block_lookup): Constify.
2013-03-12 09:51:37 -06:00
|
|
|
|
const struct block *block = NULL, *fn_block;
|
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
Tom Tromey <tromey@redhat.com>
Thiago Jung Bauermann <bauerman@br.ibm.com>
* python/python.c (_initialize_python): Call
gdbpy_initialize_symtabs, gdbpy_initialize_symbols and
gdbpy_initialize_blocks.
* python/python-internal.h: Declare struct symbol, block and
symtab_and_line. Declare block_object_type and
symbol_object_type
(gdbpy_lookup_symbol gdbpy_block_for_pc)
(symtab_and_line_to_sal_object, symtab_to_symtab_object)
(symbol_to_symbol_object, block_to_block_object)
(gdbpy_initialize_symtabs,gdbpy_initialize_symbols)
(gdbpy_initialize_blocks ): Declare.
* python/py-frame.c (frapy_block, frapy_function, frapy_find_sal)
(frapy_select): Add methods.
(frapy_read_var): Add symbol branch.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-symbol, py-symtab,
py-block.
(SUBDIR_PYTHON_SRCS): Likewise.
(py-symbol.o): New rule.
(py-symtab.o): Likewise.
(py-block.o): Likewise.
* python/py-symbol.c: New file.
* python/py-symtab.c: Likewise.
* python/py-block.c: Likewise.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* Makefile.in: Add py-block and py-symbol.
* gdb.python/py-symbol.exp: New File.
* gdb.python/py-symtab.exp: New File.
* gdb.python/py-block.exp: New File.
* gdb.python/py-symbol.c: New File.
* gdb.python/py-block.c: New File.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Frames In Python): Add block, find_sal, function
and select method descriptions.
(Python API): Add Blocks In Python, Symbols in Python and Symbol
Tables in Python to menu.
(Blocks In Python): New node.
(Symbols In Python): New node.
(Symbol Tables in Python): New node.
2010-02-24 21:18:28 +00:00
|
|
|
|
|
2019-04-03 16:02:42 -06:00
|
|
|
|
try
|
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
Tom Tromey <tromey@redhat.com>
Thiago Jung Bauermann <bauerman@br.ibm.com>
* python/python.c (_initialize_python): Call
gdbpy_initialize_symtabs, gdbpy_initialize_symbols and
gdbpy_initialize_blocks.
* python/python-internal.h: Declare struct symbol, block and
symtab_and_line. Declare block_object_type and
symbol_object_type
(gdbpy_lookup_symbol gdbpy_block_for_pc)
(symtab_and_line_to_sal_object, symtab_to_symtab_object)
(symbol_to_symbol_object, block_to_block_object)
(gdbpy_initialize_symtabs,gdbpy_initialize_symbols)
(gdbpy_initialize_blocks ): Declare.
* python/py-frame.c (frapy_block, frapy_function, frapy_find_sal)
(frapy_select): Add methods.
(frapy_read_var): Add symbol branch.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-symbol, py-symtab,
py-block.
(SUBDIR_PYTHON_SRCS): Likewise.
(py-symbol.o): New rule.
(py-symtab.o): Likewise.
(py-block.o): Likewise.
* python/py-symbol.c: New file.
* python/py-symtab.c: Likewise.
* python/py-block.c: Likewise.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* Makefile.in: Add py-block and py-symbol.
* gdb.python/py-symbol.exp: New File.
* gdb.python/py-symtab.exp: New File.
* gdb.python/py-block.exp: New File.
* gdb.python/py-symbol.c: New File.
* gdb.python/py-block.c: New File.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Frames In Python): Add block, find_sal, function
and select method descriptions.
(Python API): Add Blocks In Python, Symbols in Python and Symbol
Tables in Python to menu.
(Blocks In Python): New node.
(Symbols In Python): New node.
(Symbol Tables in Python): New node.
2010-02-24 21:18:28 +00:00
|
|
|
|
{
|
2011-12-23 17:06:16 +00:00
|
|
|
|
FRAPY_REQUIRE_VALID (self, frame);
|
2011-01-06 17:16:58 +00:00
|
|
|
|
block = get_frame_block (frame, NULL);
|
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
Tom Tromey <tromey@redhat.com>
Thiago Jung Bauermann <bauerman@br.ibm.com>
* python/python.c (_initialize_python): Call
gdbpy_initialize_symtabs, gdbpy_initialize_symbols and
gdbpy_initialize_blocks.
* python/python-internal.h: Declare struct symbol, block and
symtab_and_line. Declare block_object_type and
symbol_object_type
(gdbpy_lookup_symbol gdbpy_block_for_pc)
(symtab_and_line_to_sal_object, symtab_to_symtab_object)
(symbol_to_symbol_object, block_to_block_object)
(gdbpy_initialize_symtabs,gdbpy_initialize_symbols)
(gdbpy_initialize_blocks ): Declare.
* python/py-frame.c (frapy_block, frapy_function, frapy_find_sal)
(frapy_select): Add methods.
(frapy_read_var): Add symbol branch.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-symbol, py-symtab,
py-block.
(SUBDIR_PYTHON_SRCS): Likewise.
(py-symbol.o): New rule.
(py-symtab.o): Likewise.
(py-block.o): Likewise.
* python/py-symbol.c: New file.
* python/py-symtab.c: Likewise.
* python/py-block.c: Likewise.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* Makefile.in: Add py-block and py-symbol.
* gdb.python/py-symbol.exp: New File.
* gdb.python/py-symtab.exp: New File.
* gdb.python/py-block.exp: New File.
* gdb.python/py-symbol.c: New File.
* gdb.python/py-block.c: New File.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Frames In Python): Add block, find_sal, function
and select method descriptions.
(Python API): Add Blocks In Python, Symbols in Python and Symbol
Tables in Python to menu.
(Blocks In Python): New node.
(Symbols In Python): New node.
(Symbol Tables in Python): New node.
2010-02-24 21:18:28 +00:00
|
|
|
|
}
|
2019-04-03 15:59:07 -06:00
|
|
|
|
catch (const gdb_exception &except)
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
{
|
2024-09-24 13:06:32 +02:00
|
|
|
|
return gdbpy_handle_gdb_exception (nullptr, except);
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
}
|
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
Tom Tromey <tromey@redhat.com>
Thiago Jung Bauermann <bauerman@br.ibm.com>
* python/python.c (_initialize_python): Call
gdbpy_initialize_symtabs, gdbpy_initialize_symbols and
gdbpy_initialize_blocks.
* python/python-internal.h: Declare struct symbol, block and
symtab_and_line. Declare block_object_type and
symbol_object_type
(gdbpy_lookup_symbol gdbpy_block_for_pc)
(symtab_and_line_to_sal_object, symtab_to_symtab_object)
(symbol_to_symbol_object, block_to_block_object)
(gdbpy_initialize_symtabs,gdbpy_initialize_symbols)
(gdbpy_initialize_blocks ): Declare.
* python/py-frame.c (frapy_block, frapy_function, frapy_find_sal)
(frapy_select): Add methods.
(frapy_read_var): Add symbol branch.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-symbol, py-symtab,
py-block.
(SUBDIR_PYTHON_SRCS): Likewise.
(py-symbol.o): New rule.
(py-symtab.o): Likewise.
(py-block.o): Likewise.
* python/py-symbol.c: New file.
* python/py-symtab.c: Likewise.
* python/py-block.c: Likewise.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* Makefile.in: Add py-block and py-symbol.
* gdb.python/py-symbol.exp: New File.
* gdb.python/py-symtab.exp: New File.
* gdb.python/py-block.exp: New File.
* gdb.python/py-symbol.c: New File.
* gdb.python/py-block.c: New File.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Frames In Python): Add block, find_sal, function
and select method descriptions.
(Python API): Add Blocks In Python, Symbols in Python and Symbol
Tables in Python to menu.
(Blocks In Python): New node.
(Symbols In Python): New node.
(Symbol Tables in Python): New node.
2010-02-24 21:18:28 +00:00
|
|
|
|
|
2011-01-06 17:16:58 +00:00
|
|
|
|
for (fn_block = block;
|
2022-01-28 11:19:50 -05:00
|
|
|
|
fn_block != NULL && fn_block->function () == NULL;
|
2022-01-28 11:41:38 -05:00
|
|
|
|
fn_block = fn_block->superblock ())
|
2011-01-06 17:16:58 +00:00
|
|
|
|
;
|
|
|
|
|
|
|
2022-01-28 11:19:50 -05:00
|
|
|
|
if (block == NULL || fn_block == NULL || fn_block->function () == NULL)
|
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
Tom Tromey <tromey@redhat.com>
Thiago Jung Bauermann <bauerman@br.ibm.com>
* python/python.c (_initialize_python): Call
gdbpy_initialize_symtabs, gdbpy_initialize_symbols and
gdbpy_initialize_blocks.
* python/python-internal.h: Declare struct symbol, block and
symtab_and_line. Declare block_object_type and
symbol_object_type
(gdbpy_lookup_symbol gdbpy_block_for_pc)
(symtab_and_line_to_sal_object, symtab_to_symtab_object)
(symbol_to_symbol_object, block_to_block_object)
(gdbpy_initialize_symtabs,gdbpy_initialize_symbols)
(gdbpy_initialize_blocks ): Declare.
* python/py-frame.c (frapy_block, frapy_function, frapy_find_sal)
(frapy_select): Add methods.
(frapy_read_var): Add symbol branch.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-symbol, py-symtab,
py-block.
(SUBDIR_PYTHON_SRCS): Likewise.
(py-symbol.o): New rule.
(py-symtab.o): Likewise.
(py-block.o): Likewise.
* python/py-symbol.c: New file.
* python/py-symtab.c: Likewise.
* python/py-block.c: Likewise.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* Makefile.in: Add py-block and py-symbol.
* gdb.python/py-symbol.exp: New File.
* gdb.python/py-symtab.exp: New File.
* gdb.python/py-block.exp: New File.
* gdb.python/py-symbol.c: New File.
* gdb.python/py-block.c: New File.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Frames In Python): Add block, find_sal, function
and select method descriptions.
(Python API): Add Blocks In Python, Symbols in Python and Symbol
Tables in Python to menu.
(Blocks In Python): New node.
(Symbols In Python): New node.
(Symbol Tables in Python): New node.
2010-02-24 21:18:28 +00:00
|
|
|
|
{
|
|
|
|
|
|
PyErr_SetString (PyExc_RuntimeError,
|
2013-11-23 14:36:57 -08:00
|
|
|
|
_("Cannot locate block for frame."));
|
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
Tom Tromey <tromey@redhat.com>
Thiago Jung Bauermann <bauerman@br.ibm.com>
* python/python.c (_initialize_python): Call
gdbpy_initialize_symtabs, gdbpy_initialize_symbols and
gdbpy_initialize_blocks.
* python/python-internal.h: Declare struct symbol, block and
symtab_and_line. Declare block_object_type and
symbol_object_type
(gdbpy_lookup_symbol gdbpy_block_for_pc)
(symtab_and_line_to_sal_object, symtab_to_symtab_object)
(symbol_to_symbol_object, block_to_block_object)
(gdbpy_initialize_symtabs,gdbpy_initialize_symbols)
(gdbpy_initialize_blocks ): Declare.
* python/py-frame.c (frapy_block, frapy_function, frapy_find_sal)
(frapy_select): Add methods.
(frapy_read_var): Add symbol branch.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-symbol, py-symtab,
py-block.
(SUBDIR_PYTHON_SRCS): Likewise.
(py-symbol.o): New rule.
(py-symtab.o): Likewise.
(py-block.o): Likewise.
* python/py-symbol.c: New file.
* python/py-symtab.c: Likewise.
* python/py-block.c: Likewise.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* Makefile.in: Add py-block and py-symbol.
* gdb.python/py-symbol.exp: New File.
* gdb.python/py-symtab.exp: New File.
* gdb.python/py-block.exp: New File.
* gdb.python/py-symbol.c: New File.
* gdb.python/py-block.c: New File.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Frames In Python): Add block, find_sal, function
and select method descriptions.
(Python API): Add Blocks In Python, Symbols in Python and Symbol
Tables in Python to menu.
(Blocks In Python): New node.
(Symbols In Python): New node.
(Symbol Tables in Python): New node.
2010-02-24 21:18:28 +00:00
|
|
|
|
return NULL;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2026-02-20 12:50:48 -07:00
|
|
|
|
return block_to_block_object (block,
|
|
|
|
|
|
fn_block->function ()->objfile ()).release ();
|
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
Tom Tromey <tromey@redhat.com>
Thiago Jung Bauermann <bauerman@br.ibm.com>
* python/python.c (_initialize_python): Call
gdbpy_initialize_symtabs, gdbpy_initialize_symbols and
gdbpy_initialize_blocks.
* python/python-internal.h: Declare struct symbol, block and
symtab_and_line. Declare block_object_type and
symbol_object_type
(gdbpy_lookup_symbol gdbpy_block_for_pc)
(symtab_and_line_to_sal_object, symtab_to_symtab_object)
(symbol_to_symbol_object, block_to_block_object)
(gdbpy_initialize_symtabs,gdbpy_initialize_symbols)
(gdbpy_initialize_blocks ): Declare.
* python/py-frame.c (frapy_block, frapy_function, frapy_find_sal)
(frapy_select): Add methods.
(frapy_read_var): Add symbol branch.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-symbol, py-symtab,
py-block.
(SUBDIR_PYTHON_SRCS): Likewise.
(py-symbol.o): New rule.
(py-symtab.o): Likewise.
(py-block.o): Likewise.
* python/py-symbol.c: New file.
* python/py-symtab.c: Likewise.
* python/py-block.c: Likewise.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* Makefile.in: Add py-block and py-symbol.
* gdb.python/py-symbol.exp: New File.
* gdb.python/py-symtab.exp: New File.
* gdb.python/py-block.exp: New File.
* gdb.python/py-symbol.c: New File.
* gdb.python/py-block.c: New File.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Frames In Python): Add block, find_sal, function
and select method descriptions.
(Python API): Add Blocks In Python, Symbols in Python and Symbol
Tables in Python to menu.
(Blocks In Python): New node.
(Symbols In Python): New node.
(Symbol Tables in Python): New node.
2010-02-24 21:18:28 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* Implementation of gdb.Frame.function (self) -> gdb.Symbol.
|
|
|
|
|
|
Returns the symbol for the function corresponding to this frame. */
|
|
|
|
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
|
|
frapy_function (PyObject *self, PyObject *args)
|
|
|
|
|
|
{
|
|
|
|
|
|
struct symbol *sym = NULL;
|
2022-07-25 14:06:35 -03:00
|
|
|
|
frame_info_ptr frame;
|
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
Tom Tromey <tromey@redhat.com>
Thiago Jung Bauermann <bauerman@br.ibm.com>
* python/python.c (_initialize_python): Call
gdbpy_initialize_symtabs, gdbpy_initialize_symbols and
gdbpy_initialize_blocks.
* python/python-internal.h: Declare struct symbol, block and
symtab_and_line. Declare block_object_type and
symbol_object_type
(gdbpy_lookup_symbol gdbpy_block_for_pc)
(symtab_and_line_to_sal_object, symtab_to_symtab_object)
(symbol_to_symbol_object, block_to_block_object)
(gdbpy_initialize_symtabs,gdbpy_initialize_symbols)
(gdbpy_initialize_blocks ): Declare.
* python/py-frame.c (frapy_block, frapy_function, frapy_find_sal)
(frapy_select): Add methods.
(frapy_read_var): Add symbol branch.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-symbol, py-symtab,
py-block.
(SUBDIR_PYTHON_SRCS): Likewise.
(py-symbol.o): New rule.
(py-symtab.o): Likewise.
(py-block.o): Likewise.
* python/py-symbol.c: New file.
* python/py-symtab.c: Likewise.
* python/py-block.c: Likewise.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* Makefile.in: Add py-block and py-symbol.
* gdb.python/py-symbol.exp: New File.
* gdb.python/py-symtab.exp: New File.
* gdb.python/py-block.exp: New File.
* gdb.python/py-symbol.c: New File.
* gdb.python/py-block.c: New File.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Frames In Python): Add block, find_sal, function
and select method descriptions.
(Python API): Add Blocks In Python, Symbols in Python and Symbol
Tables in Python to menu.
(Blocks In Python): New node.
(Symbols In Python): New node.
(Symbol Tables in Python): New node.
2010-02-24 21:18:28 +00:00
|
|
|
|
|
2019-04-03 16:02:42 -06:00
|
|
|
|
try
|
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
Tom Tromey <tromey@redhat.com>
Thiago Jung Bauermann <bauerman@br.ibm.com>
* python/python.c (_initialize_python): Call
gdbpy_initialize_symtabs, gdbpy_initialize_symbols and
gdbpy_initialize_blocks.
* python/python-internal.h: Declare struct symbol, block and
symtab_and_line. Declare block_object_type and
symbol_object_type
(gdbpy_lookup_symbol gdbpy_block_for_pc)
(symtab_and_line_to_sal_object, symtab_to_symtab_object)
(symbol_to_symbol_object, block_to_block_object)
(gdbpy_initialize_symtabs,gdbpy_initialize_symbols)
(gdbpy_initialize_blocks ): Declare.
* python/py-frame.c (frapy_block, frapy_function, frapy_find_sal)
(frapy_select): Add methods.
(frapy_read_var): Add symbol branch.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-symbol, py-symtab,
py-block.
(SUBDIR_PYTHON_SRCS): Likewise.
(py-symbol.o): New rule.
(py-symtab.o): Likewise.
(py-block.o): Likewise.
* python/py-symbol.c: New file.
* python/py-symtab.c: Likewise.
* python/py-block.c: Likewise.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* Makefile.in: Add py-block and py-symbol.
* gdb.python/py-symbol.exp: New File.
* gdb.python/py-symtab.exp: New File.
* gdb.python/py-block.exp: New File.
* gdb.python/py-symbol.c: New File.
* gdb.python/py-block.c: New File.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Frames In Python): Add block, find_sal, function
and select method descriptions.
(Python API): Add Blocks In Python, Symbols in Python and Symbol
Tables in Python to menu.
(Blocks In Python): New node.
(Symbols In Python): New node.
(Symbol Tables in Python): New node.
2010-02-24 21:18:28 +00:00
|
|
|
|
{
|
2016-06-12 20:45:29 -06:00
|
|
|
|
enum language funlang;
|
|
|
|
|
|
|
2011-12-23 17:06:16 +00:00
|
|
|
|
FRAPY_REQUIRE_VALID (self, frame);
|
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
Tom Tromey <tromey@redhat.com>
Thiago Jung Bauermann <bauerman@br.ibm.com>
* python/python.c (_initialize_python): Call
gdbpy_initialize_symtabs, gdbpy_initialize_symbols and
gdbpy_initialize_blocks.
* python/python-internal.h: Declare struct symbol, block and
symtab_and_line. Declare block_object_type and
symbol_object_type
(gdbpy_lookup_symbol gdbpy_block_for_pc)
(symtab_and_line_to_sal_object, symtab_to_symtab_object)
(symbol_to_symbol_object, block_to_block_object)
(gdbpy_initialize_symtabs,gdbpy_initialize_symbols)
(gdbpy_initialize_blocks ): Declare.
* python/py-frame.c (frapy_block, frapy_function, frapy_find_sal)
(frapy_select): Add methods.
(frapy_read_var): Add symbol branch.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-symbol, py-symtab,
py-block.
(SUBDIR_PYTHON_SRCS): Likewise.
(py-symbol.o): New rule.
(py-symtab.o): Likewise.
(py-block.o): Likewise.
* python/py-symbol.c: New file.
* python/py-symtab.c: Likewise.
* python/py-block.c: Likewise.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* Makefile.in: Add py-block and py-symbol.
* gdb.python/py-symbol.exp: New File.
* gdb.python/py-symtab.exp: New File.
* gdb.python/py-block.exp: New File.
* gdb.python/py-symbol.c: New File.
* gdb.python/py-block.c: New File.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Frames In Python): Add block, find_sal, function
and select method descriptions.
(Python API): Add Blocks In Python, Symbols in Python and Symbol
Tables in Python to menu.
(Blocks In Python): New node.
(Symbols In Python): New node.
(Symbol Tables in Python): New node.
2010-02-24 21:18:28 +00:00
|
|
|
|
|
2017-09-09 10:14:52 -06:00
|
|
|
|
gdb::unique_xmalloc_ptr<char> funname
|
|
|
|
|
|
= find_frame_funname (frame, &funlang, &sym);
|
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
Tom Tromey <tromey@redhat.com>
Thiago Jung Bauermann <bauerman@br.ibm.com>
* python/python.c (_initialize_python): Call
gdbpy_initialize_symtabs, gdbpy_initialize_symbols and
gdbpy_initialize_blocks.
* python/python-internal.h: Declare struct symbol, block and
symtab_and_line. Declare block_object_type and
symbol_object_type
(gdbpy_lookup_symbol gdbpy_block_for_pc)
(symtab_and_line_to_sal_object, symtab_to_symtab_object)
(symbol_to_symbol_object, block_to_block_object)
(gdbpy_initialize_symtabs,gdbpy_initialize_symbols)
(gdbpy_initialize_blocks ): Declare.
* python/py-frame.c (frapy_block, frapy_function, frapy_find_sal)
(frapy_select): Add methods.
(frapy_read_var): Add symbol branch.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-symbol, py-symtab,
py-block.
(SUBDIR_PYTHON_SRCS): Likewise.
(py-symbol.o): New rule.
(py-symtab.o): Likewise.
(py-block.o): Likewise.
* python/py-symbol.c: New file.
* python/py-symtab.c: Likewise.
* python/py-block.c: Likewise.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* Makefile.in: Add py-block and py-symbol.
* gdb.python/py-symbol.exp: New File.
* gdb.python/py-symtab.exp: New File.
* gdb.python/py-block.exp: New File.
* gdb.python/py-symbol.c: New File.
* gdb.python/py-block.c: New File.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Frames In Python): Add block, find_sal, function
and select method descriptions.
(Python API): Add Blocks In Python, Symbols in Python and Symbol
Tables in Python to menu.
(Blocks In Python): New node.
(Symbols In Python): New node.
(Symbol Tables in Python): New node.
2010-02-24 21:18:28 +00:00
|
|
|
|
}
|
2019-04-03 15:59:07 -06:00
|
|
|
|
catch (const gdb_exception &except)
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
{
|
2024-09-24 13:06:32 +02:00
|
|
|
|
return gdbpy_handle_gdb_exception (nullptr, except);
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
}
|
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
Tom Tromey <tromey@redhat.com>
Thiago Jung Bauermann <bauerman@br.ibm.com>
* python/python.c (_initialize_python): Call
gdbpy_initialize_symtabs, gdbpy_initialize_symbols and
gdbpy_initialize_blocks.
* python/python-internal.h: Declare struct symbol, block and
symtab_and_line. Declare block_object_type and
symbol_object_type
(gdbpy_lookup_symbol gdbpy_block_for_pc)
(symtab_and_line_to_sal_object, symtab_to_symtab_object)
(symbol_to_symbol_object, block_to_block_object)
(gdbpy_initialize_symtabs,gdbpy_initialize_symbols)
(gdbpy_initialize_blocks ): Declare.
* python/py-frame.c (frapy_block, frapy_function, frapy_find_sal)
(frapy_select): Add methods.
(frapy_read_var): Add symbol branch.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-symbol, py-symtab,
py-block.
(SUBDIR_PYTHON_SRCS): Likewise.
(py-symbol.o): New rule.
(py-symtab.o): Likewise.
(py-block.o): Likewise.
* python/py-symbol.c: New file.
* python/py-symtab.c: Likewise.
* python/py-block.c: Likewise.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* Makefile.in: Add py-block and py-symbol.
* gdb.python/py-symbol.exp: New File.
* gdb.python/py-symtab.exp: New File.
* gdb.python/py-block.exp: New File.
* gdb.python/py-symbol.c: New File.
* gdb.python/py-block.c: New File.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Frames In Python): Add block, find_sal, function
and select method descriptions.
(Python API): Add Blocks In Python, Symbols in Python and Symbol
Tables in Python to menu.
(Blocks In Python): New node.
(Symbols In Python): New node.
(Symbol Tables in Python): New node.
2010-02-24 21:18:28 +00:00
|
|
|
|
|
|
|
|
|
|
if (sym)
|
2026-02-20 12:46:46 -07:00
|
|
|
|
return symbol_to_symbol_object (sym).release ();
|
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
Tom Tromey <tromey@redhat.com>
Thiago Jung Bauermann <bauerman@br.ibm.com>
* python/python.c (_initialize_python): Call
gdbpy_initialize_symtabs, gdbpy_initialize_symbols and
gdbpy_initialize_blocks.
* python/python-internal.h: Declare struct symbol, block and
symtab_and_line. Declare block_object_type and
symbol_object_type
(gdbpy_lookup_symbol gdbpy_block_for_pc)
(symtab_and_line_to_sal_object, symtab_to_symtab_object)
(symbol_to_symbol_object, block_to_block_object)
(gdbpy_initialize_symtabs,gdbpy_initialize_symbols)
(gdbpy_initialize_blocks ): Declare.
* python/py-frame.c (frapy_block, frapy_function, frapy_find_sal)
(frapy_select): Add methods.
(frapy_read_var): Add symbol branch.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-symbol, py-symtab,
py-block.
(SUBDIR_PYTHON_SRCS): Likewise.
(py-symbol.o): New rule.
(py-symtab.o): Likewise.
(py-block.o): Likewise.
* python/py-symbol.c: New file.
* python/py-symtab.c: Likewise.
* python/py-block.c: Likewise.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* Makefile.in: Add py-block and py-symbol.
* gdb.python/py-symbol.exp: New File.
* gdb.python/py-symtab.exp: New File.
* gdb.python/py-block.exp: New File.
* gdb.python/py-symbol.c: New File.
* gdb.python/py-block.c: New File.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Frames In Python): Add block, find_sal, function
and select method descriptions.
(Python API): Add Blocks In Python, Symbols in Python and Symbol
Tables in Python to menu.
(Blocks In Python): New node.
(Symbols In Python): New node.
(Symbol Tables in Python): New node.
2010-02-24 21:18:28 +00:00
|
|
|
|
|
2026-05-15 21:38:12 +02:00
|
|
|
|
return py_none ().release ();
|
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
Tom Tromey <tromey@redhat.com>
Thiago Jung Bauermann <bauerman@br.ibm.com>
* python/python.c (_initialize_python): Call
gdbpy_initialize_symtabs, gdbpy_initialize_symbols and
gdbpy_initialize_blocks.
* python/python-internal.h: Declare struct symbol, block and
symtab_and_line. Declare block_object_type and
symbol_object_type
(gdbpy_lookup_symbol gdbpy_block_for_pc)
(symtab_and_line_to_sal_object, symtab_to_symtab_object)
(symbol_to_symbol_object, block_to_block_object)
(gdbpy_initialize_symtabs,gdbpy_initialize_symbols)
(gdbpy_initialize_blocks ): Declare.
* python/py-frame.c (frapy_block, frapy_function, frapy_find_sal)
(frapy_select): Add methods.
(frapy_read_var): Add symbol branch.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-symbol, py-symtab,
py-block.
(SUBDIR_PYTHON_SRCS): Likewise.
(py-symbol.o): New rule.
(py-symtab.o): Likewise.
(py-block.o): Likewise.
* python/py-symbol.c: New file.
* python/py-symtab.c: Likewise.
* python/py-block.c: Likewise.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* Makefile.in: Add py-block and py-symbol.
* gdb.python/py-symbol.exp: New File.
* gdb.python/py-symtab.exp: New File.
* gdb.python/py-block.exp: New File.
* gdb.python/py-symbol.c: New File.
* gdb.python/py-block.c: New File.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Frames In Python): Add block, find_sal, function
and select method descriptions.
(Python API): Add Blocks In Python, Symbols in Python and Symbol
Tables in Python to menu.
(Blocks In Python): New node.
(Symbols In Python): New node.
(Symbol Tables in Python): New node.
2010-02-24 21:18:28 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
2009-03-30 19:54:33 +00:00
|
|
|
|
/* Convert a frame_info struct to a Python Frame object.
|
|
|
|
|
|
Sets a Python exception and returns NULL on error. */
|
|
|
|
|
|
|
2026-02-20 13:06:56 -07:00
|
|
|
|
gdbpy_ref<>
|
gdb: pass frames as `const frame_info_ptr &`
We currently pass frames to function by value, as `frame_info_ptr`.
This is somewhat expensive:
- the size of `frame_info_ptr` is 64 bytes, which is a bit big to pass
by value
- the constructors and destructor link/unlink the object in the global
`frame_info_ptr::frame_list` list. This is an `intrusive_list`, so
it's not so bad: it's just assigning a few points, there's no memory
allocation as if it was `std::list`, but still it's useless to do
that over and over.
As suggested by Tom Tromey, change many function signatures to accept
`const frame_info_ptr &` instead of `frame_info_ptr`.
Some functions reassign their `frame_info_ptr` parameter, like:
void
the_func (frame_info_ptr frame)
{
for (; frame != nullptr; frame = get_prev_frame (frame))
{
...
}
}
I wondered what to do about them, do I leave them as-is or change them
(and need to introduce a separate local variable that can be
re-assigned). I opted for the later for consistency. It might not be
clear why some functions take `const frame_info_ptr &` while others take
`frame_info_ptr`. Also, if a function took a `frame_info_ptr` because
it did re-assign its parameter, I doubt that we would think to change it
to `const frame_info_ptr &` should the implementation change such that
it doesn't need to take `frame_info_ptr` anymore. It seems better to
have a simple rule and apply it everywhere.
Change-Id: I59d10addef687d157f82ccf4d54f5dde9a963fd0
Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-02-19 13:07:47 -05:00
|
|
|
|
frame_info_to_frame_object (const frame_info_ptr &frame)
|
2009-03-30 19:54:33 +00:00
|
|
|
|
{
|
2017-01-11 16:28:43 -07:00
|
|
|
|
gdbpy_ref<frame_object> frame_obj (PyObject_New (frame_object,
|
|
|
|
|
|
&frame_object_type));
|
2009-03-30 19:54:33 +00:00
|
|
|
|
if (frame_obj == NULL)
|
2013-05-17 16:52:34 +00:00
|
|
|
|
return NULL;
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
2019-04-03 16:02:42 -06:00
|
|
|
|
try
|
2009-03-30 19:54:33 +00:00
|
|
|
|
{
|
gdb/python: remove frame_object::frame_id_is_next as unnecessary
Remove the frame_object::frame_id_is_next field. This has been part
of how Python handles frames since this code was first added in commit
f8f6f20b6e37e6d219940fcad58b1f66124d11c1 back in 2009. The motivation
for this field can be found in a couple of comments, there's this one
on frame_id_is_next:
/* Marks that the FRAME_ID member actually holds the ID of the frame next
to this, and not this frames' ID itself. This is a hack to permit Python
frame objects which represent invalid frames (i.e., the last frame_info
in a corrupt stack). The problem arises from the fact that this code
relies on FRAME_ID to uniquely identify a frame, which is not always true
for the last "frame" in a corrupt stack (it can have a null ID, or the same
ID as the previous frame). Whenever get_prev_frame returns NULL, we
record the frame_id of the next frame and set FRAME_ID_IS_NEXT to 1. */
And this one in frame_info_to_frame_object:
/* Try to get the previous frame, to determine if this is the last frame
in a corrupt stack. If so, we need to store the frame_id of the next
frame and not of this one (which is possibly invalid). */
This field is dealing with a problem that was present in older
versions of GDB where not every stack frame had a valid frame-id, if
the stack was corrupted in some way then the last frame might have an
invalid frame-id. However, that is no longer the case. With current
GDB there is a promise that every frame has a valid frame-id. I don't
have a single commit to point to where this became the reality, but it
is my understanding of current GDB.
As an example, the frame-id of every frame (except #0) is computed as
the frame is created, any frames with a duplicate frame-id, or any
errors during computation of the frame-id, and the new frame is
discarded.
Additionally, our frame_info_ptr::reinflate mechanism relies on unique
and valid frame-ids.
The problem with the existing code is that the last frame in a
corrupted stack will hold the frame-id of the next frame, that is, the
more inner frame. This means we have two frames holding the same
frame-id, and the only difference is the frame_id_is_next flag.
However, the frapy_str function, which prints a string representation
of the frame, doesn't take frame_id_is_next into account, so printing
the last two frames in a corrupted stack, will print the same
frame-id.
We could fix this in frapy_str and also frapy_repr by checking the
frame_id_is_next flag and then fetching the previous frame-id, but
this would still assume that the previous frame has a valid-id, so we
might as well just drop the frame_id_is_next flag and make everything
simpler.
There's a new test which exposes the incorrectly printed frame-id
problem.
While testing I needed to "fix" the results for two existing tests.
In frame_info_to_frame_object, in order to figure out if we should use
the next frame, we called get_prev_frame. This would cause GDB to
always unwind 1 extra level of the stack.
What this means is that, if there is an error, or some diagnostic
output, when unwinding frame #1, then this will show up when trying to
access frame #0 via the Python API as frame_info_to_frame_object on
frame #0 would call get_prev_frame, which would then unwind frame #1.
After this commit this is no longer the case. We only see
output (either errors, or diagnostic output) associated with frame #1
when we actually try to unwind to frame #1. The two tests that needed
updating were expecting output associated with frame #1 while printing
frame #0. This is now fixed and the output for frame #1 occurs later
on. I think this is an improvement.
2026-06-01 16:07:49 +01:00
|
|
|
|
frame_obj->frame_id = get_frame_id (frame);
|
2011-10-27 09:14:27 +00:00
|
|
|
|
frame_obj->gdbarch = get_frame_arch (frame);
|
|
|
|
|
|
}
|
2019-04-03 15:59:07 -06:00
|
|
|
|
catch (const gdb_exception &except)
|
2013-10-02 08:37:11 +00:00
|
|
|
|
{
|
2024-09-24 13:06:32 +02:00
|
|
|
|
return gdbpy_handle_gdb_exception (nullptr, except);
|
2013-10-02 08:37:11 +00:00
|
|
|
|
}
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
|
2026-02-21 12:07:37 -07:00
|
|
|
|
return frame_obj;
|
2009-03-30 19:54:33 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* Implementation of gdb.Frame.older (self) -> gdb.Frame.
|
|
|
|
|
|
Returns the frame immediately older (outer) to this frame, or None if
|
|
|
|
|
|
there isn't one. */
|
|
|
|
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
|
|
frapy_older (PyObject *self, PyObject *args)
|
|
|
|
|
|
{
|
2022-07-25 14:06:35 -03:00
|
|
|
|
frame_info_ptr frame, prev = NULL;
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
2019-04-03 16:02:42 -06:00
|
|
|
|
try
|
2009-03-30 19:54:33 +00:00
|
|
|
|
{
|
2011-12-23 17:06:16 +00:00
|
|
|
|
FRAPY_REQUIRE_VALID (self, frame);
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
|
|
|
|
|
prev = get_prev_frame (frame);
|
|
|
|
|
|
}
|
2019-04-03 15:59:07 -06:00
|
|
|
|
catch (const gdb_exception &except)
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
{
|
2024-09-24 13:06:32 +02:00
|
|
|
|
return gdbpy_handle_gdb_exception (nullptr, except);
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
}
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
2026-02-20 13:06:56 -07:00
|
|
|
|
gdbpy_ref<> prev_obj;
|
2013-05-20 20:37:06 +00:00
|
|
|
|
if (prev)
|
2019-01-02 09:30:49 -07:00
|
|
|
|
prev_obj = frame_info_to_frame_object (prev);
|
2013-05-20 20:37:06 +00:00
|
|
|
|
else
|
2026-05-15 21:38:12 +02:00
|
|
|
|
prev_obj = py_none ();
|
2013-05-20 20:37:06 +00:00
|
|
|
|
|
2026-02-20 13:06:56 -07:00
|
|
|
|
return prev_obj.release ();
|
2009-03-30 19:54:33 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* Implementation of gdb.Frame.newer (self) -> gdb.Frame.
|
|
|
|
|
|
Returns the frame immediately newer (inner) to this frame, or None if
|
|
|
|
|
|
there isn't one. */
|
|
|
|
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
|
|
frapy_newer (PyObject *self, PyObject *args)
|
|
|
|
|
|
{
|
2022-07-25 14:06:35 -03:00
|
|
|
|
frame_info_ptr frame, next = NULL;
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
2019-04-03 16:02:42 -06:00
|
|
|
|
try
|
2009-03-30 19:54:33 +00:00
|
|
|
|
{
|
2011-12-23 17:06:16 +00:00
|
|
|
|
FRAPY_REQUIRE_VALID (self, frame);
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
|
|
|
|
|
next = get_next_frame (frame);
|
|
|
|
|
|
}
|
2019-04-03 15:59:07 -06:00
|
|
|
|
catch (const gdb_exception &except)
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
{
|
2024-09-24 13:06:32 +02:00
|
|
|
|
return gdbpy_handle_gdb_exception (nullptr, except);
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
}
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
2026-02-20 13:06:56 -07:00
|
|
|
|
gdbpy_ref<> next_obj;
|
2013-05-20 20:37:06 +00:00
|
|
|
|
if (next)
|
2019-01-02 09:30:49 -07:00
|
|
|
|
next_obj = frame_info_to_frame_object (next);
|
2013-05-20 20:37:06 +00:00
|
|
|
|
else
|
2026-05-15 21:38:12 +02:00
|
|
|
|
next_obj = py_none ();
|
2013-05-20 20:37:06 +00:00
|
|
|
|
|
2026-02-20 13:06:56 -07:00
|
|
|
|
return next_obj.release ();
|
2009-03-30 19:54:33 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
Tom Tromey <tromey@redhat.com>
Thiago Jung Bauermann <bauerman@br.ibm.com>
* python/python.c (_initialize_python): Call
gdbpy_initialize_symtabs, gdbpy_initialize_symbols and
gdbpy_initialize_blocks.
* python/python-internal.h: Declare struct symbol, block and
symtab_and_line. Declare block_object_type and
symbol_object_type
(gdbpy_lookup_symbol gdbpy_block_for_pc)
(symtab_and_line_to_sal_object, symtab_to_symtab_object)
(symbol_to_symbol_object, block_to_block_object)
(gdbpy_initialize_symtabs,gdbpy_initialize_symbols)
(gdbpy_initialize_blocks ): Declare.
* python/py-frame.c (frapy_block, frapy_function, frapy_find_sal)
(frapy_select): Add methods.
(frapy_read_var): Add symbol branch.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-symbol, py-symtab,
py-block.
(SUBDIR_PYTHON_SRCS): Likewise.
(py-symbol.o): New rule.
(py-symtab.o): Likewise.
(py-block.o): Likewise.
* python/py-symbol.c: New file.
* python/py-symtab.c: Likewise.
* python/py-block.c: Likewise.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* Makefile.in: Add py-block and py-symbol.
* gdb.python/py-symbol.exp: New File.
* gdb.python/py-symtab.exp: New File.
* gdb.python/py-block.exp: New File.
* gdb.python/py-symbol.c: New File.
* gdb.python/py-block.c: New File.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Frames In Python): Add block, find_sal, function
and select method descriptions.
(Python API): Add Blocks In Python, Symbols in Python and Symbol
Tables in Python to menu.
(Blocks In Python): New node.
(Symbols In Python): New node.
(Symbol Tables in Python): New node.
2010-02-24 21:18:28 +00:00
|
|
|
|
/* Implementation of gdb.Frame.find_sal (self) -> gdb.Symtab_and_line.
|
|
|
|
|
|
Returns the frame's symtab and line. */
|
|
|
|
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
|
|
frapy_find_sal (PyObject *self, PyObject *args)
|
|
|
|
|
|
{
|
2022-07-25 14:06:35 -03:00
|
|
|
|
frame_info_ptr frame;
|
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
Tom Tromey <tromey@redhat.com>
Thiago Jung Bauermann <bauerman@br.ibm.com>
* python/python.c (_initialize_python): Call
gdbpy_initialize_symtabs, gdbpy_initialize_symbols and
gdbpy_initialize_blocks.
* python/python-internal.h: Declare struct symbol, block and
symtab_and_line. Declare block_object_type and
symbol_object_type
(gdbpy_lookup_symbol gdbpy_block_for_pc)
(symtab_and_line_to_sal_object, symtab_to_symtab_object)
(symbol_to_symbol_object, block_to_block_object)
(gdbpy_initialize_symtabs,gdbpy_initialize_symbols)
(gdbpy_initialize_blocks ): Declare.
* python/py-frame.c (frapy_block, frapy_function, frapy_find_sal)
(frapy_select): Add methods.
(frapy_read_var): Add symbol branch.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-symbol, py-symtab,
py-block.
(SUBDIR_PYTHON_SRCS): Likewise.
(py-symbol.o): New rule.
(py-symtab.o): Likewise.
(py-block.o): Likewise.
* python/py-symbol.c: New file.
* python/py-symtab.c: Likewise.
* python/py-block.c: Likewise.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* Makefile.in: Add py-block and py-symbol.
* gdb.python/py-symbol.exp: New File.
* gdb.python/py-symtab.exp: New File.
* gdb.python/py-block.exp: New File.
* gdb.python/py-symbol.c: New File.
* gdb.python/py-block.c: New File.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Frames In Python): Add block, find_sal, function
and select method descriptions.
(Python API): Add Blocks In Python, Symbols in Python and Symbol
Tables in Python to menu.
(Blocks In Python): New node.
(Symbols In Python): New node.
(Symbol Tables in Python): New node.
2010-02-24 21:18:28 +00:00
|
|
|
|
|
2019-04-03 16:02:42 -06:00
|
|
|
|
try
|
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
Tom Tromey <tromey@redhat.com>
Thiago Jung Bauermann <bauerman@br.ibm.com>
* python/python.c (_initialize_python): Call
gdbpy_initialize_symtabs, gdbpy_initialize_symbols and
gdbpy_initialize_blocks.
* python/python-internal.h: Declare struct symbol, block and
symtab_and_line. Declare block_object_type and
symbol_object_type
(gdbpy_lookup_symbol gdbpy_block_for_pc)
(symtab_and_line_to_sal_object, symtab_to_symtab_object)
(symbol_to_symbol_object, block_to_block_object)
(gdbpy_initialize_symtabs,gdbpy_initialize_symbols)
(gdbpy_initialize_blocks ): Declare.
* python/py-frame.c (frapy_block, frapy_function, frapy_find_sal)
(frapy_select): Add methods.
(frapy_read_var): Add symbol branch.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-symbol, py-symtab,
py-block.
(SUBDIR_PYTHON_SRCS): Likewise.
(py-symbol.o): New rule.
(py-symtab.o): Likewise.
(py-block.o): Likewise.
* python/py-symbol.c: New file.
* python/py-symtab.c: Likewise.
* python/py-block.c: Likewise.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* Makefile.in: Add py-block and py-symbol.
* gdb.python/py-symbol.exp: New File.
* gdb.python/py-symtab.exp: New File.
* gdb.python/py-block.exp: New File.
* gdb.python/py-symbol.c: New File.
* gdb.python/py-block.c: New File.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Frames In Python): Add block, find_sal, function
and select method descriptions.
(Python API): Add Blocks In Python, Symbols in Python and Symbol
Tables in Python to menu.
(Blocks In Python): New node.
(Symbols In Python): New node.
(Symbol Tables in Python): New node.
2010-02-24 21:18:28 +00:00
|
|
|
|
{
|
2011-12-23 17:06:16 +00:00
|
|
|
|
FRAPY_REQUIRE_VALID (self, frame);
|
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
Tom Tromey <tromey@redhat.com>
Thiago Jung Bauermann <bauerman@br.ibm.com>
* python/python.c (_initialize_python): Call
gdbpy_initialize_symtabs, gdbpy_initialize_symbols and
gdbpy_initialize_blocks.
* python/python-internal.h: Declare struct symbol, block and
symtab_and_line. Declare block_object_type and
symbol_object_type
(gdbpy_lookup_symbol gdbpy_block_for_pc)
(symtab_and_line_to_sal_object, symtab_to_symtab_object)
(symbol_to_symbol_object, block_to_block_object)
(gdbpy_initialize_symtabs,gdbpy_initialize_symbols)
(gdbpy_initialize_blocks ): Declare.
* python/py-frame.c (frapy_block, frapy_function, frapy_find_sal)
(frapy_select): Add methods.
(frapy_read_var): Add symbol branch.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-symbol, py-symtab,
py-block.
(SUBDIR_PYTHON_SRCS): Likewise.
(py-symbol.o): New rule.
(py-symtab.o): Likewise.
(py-block.o): Likewise.
* python/py-symbol.c: New file.
* python/py-symtab.c: Likewise.
* python/py-block.c: Likewise.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* Makefile.in: Add py-block and py-symbol.
* gdb.python/py-symbol.exp: New File.
* gdb.python/py-symtab.exp: New File.
* gdb.python/py-block.exp: New File.
* gdb.python/py-symbol.c: New File.
* gdb.python/py-block.c: New File.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Frames In Python): Add block, find_sal, function
and select method descriptions.
(Python API): Add Blocks In Python, Symbols in Python and Symbol
Tables in Python to menu.
(Blocks In Python): New node.
(Symbols In Python): New node.
(Symbol Tables in Python): New node.
2010-02-24 21:18:28 +00:00
|
|
|
|
|
2017-09-04 17:10:13 +01:00
|
|
|
|
symtab_and_line sal = find_frame_sal (frame);
|
2026-02-20 12:38:31 -07:00
|
|
|
|
return symtab_and_line_to_sal_object (sal).release ();
|
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
Tom Tromey <tromey@redhat.com>
Thiago Jung Bauermann <bauerman@br.ibm.com>
* python/python.c (_initialize_python): Call
gdbpy_initialize_symtabs, gdbpy_initialize_symbols and
gdbpy_initialize_blocks.
* python/python-internal.h: Declare struct symbol, block and
symtab_and_line. Declare block_object_type and
symbol_object_type
(gdbpy_lookup_symbol gdbpy_block_for_pc)
(symtab_and_line_to_sal_object, symtab_to_symtab_object)
(symbol_to_symbol_object, block_to_block_object)
(gdbpy_initialize_symtabs,gdbpy_initialize_symbols)
(gdbpy_initialize_blocks ): Declare.
* python/py-frame.c (frapy_block, frapy_function, frapy_find_sal)
(frapy_select): Add methods.
(frapy_read_var): Add symbol branch.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-symbol, py-symtab,
py-block.
(SUBDIR_PYTHON_SRCS): Likewise.
(py-symbol.o): New rule.
(py-symtab.o): Likewise.
(py-block.o): Likewise.
* python/py-symbol.c: New file.
* python/py-symtab.c: Likewise.
* python/py-block.c: Likewise.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* Makefile.in: Add py-block and py-symbol.
* gdb.python/py-symbol.exp: New File.
* gdb.python/py-symtab.exp: New File.
* gdb.python/py-block.exp: New File.
* gdb.python/py-symbol.c: New File.
* gdb.python/py-block.c: New File.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Frames In Python): Add block, find_sal, function
and select method descriptions.
(Python API): Add Blocks In Python, Symbols in Python and Symbol
Tables in Python to menu.
(Blocks In Python): New node.
(Symbols In Python): New node.
(Symbol Tables in Python): New node.
2010-02-24 21:18:28 +00:00
|
|
|
|
}
|
2019-04-03 15:59:07 -06:00
|
|
|
|
catch (const gdb_exception &except)
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
{
|
2024-09-24 13:06:32 +02:00
|
|
|
|
return gdbpy_handle_gdb_exception (nullptr, except);
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
}
|
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
Tom Tromey <tromey@redhat.com>
Thiago Jung Bauermann <bauerman@br.ibm.com>
* python/python.c (_initialize_python): Call
gdbpy_initialize_symtabs, gdbpy_initialize_symbols and
gdbpy_initialize_blocks.
* python/python-internal.h: Declare struct symbol, block and
symtab_and_line. Declare block_object_type and
symbol_object_type
(gdbpy_lookup_symbol gdbpy_block_for_pc)
(symtab_and_line_to_sal_object, symtab_to_symtab_object)
(symbol_to_symbol_object, block_to_block_object)
(gdbpy_initialize_symtabs,gdbpy_initialize_symbols)
(gdbpy_initialize_blocks ): Declare.
* python/py-frame.c (frapy_block, frapy_function, frapy_find_sal)
(frapy_select): Add methods.
(frapy_read_var): Add symbol branch.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-symbol, py-symtab,
py-block.
(SUBDIR_PYTHON_SRCS): Likewise.
(py-symbol.o): New rule.
(py-symtab.o): Likewise.
(py-block.o): Likewise.
* python/py-symbol.c: New file.
* python/py-symtab.c: Likewise.
* python/py-block.c: Likewise.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* Makefile.in: Add py-block and py-symbol.
* gdb.python/py-symbol.exp: New File.
* gdb.python/py-symtab.exp: New File.
* gdb.python/py-block.exp: New File.
* gdb.python/py-symbol.c: New File.
* gdb.python/py-block.c: New File.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Frames In Python): Add block, find_sal, function
and select method descriptions.
(Python API): Add Blocks In Python, Symbols in Python and Symbol
Tables in Python to menu.
(Blocks In Python): New node.
(Symbols In Python): New node.
(Symbol Tables in Python): New node.
2010-02-24 21:18:28 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
2010-02-28 21:56:50 +00:00
|
|
|
|
/* Implementation of gdb.Frame.read_var_value (self, variable,
|
|
|
|
|
|
[block]) -> gdb.Value. If the optional block argument is provided
|
|
|
|
|
|
start the search from that block, otherwise search from the frame's
|
|
|
|
|
|
current block (determined by examining the resume address of the
|
|
|
|
|
|
frame). The variable argument must be a string or an instance of a
|
2010-10-13 13:24:40 +00:00
|
|
|
|
gdb.Symbol. The block argument must be an instance of gdb.Block. Returns
|
|
|
|
|
|
NULL on error, with a python exception set. */
|
2009-03-30 19:54:33 +00:00
|
|
|
|
static PyObject *
|
gdb/python: allow Frame.read_var to accept named arguments
This commit allows Frame.read_var to accept named arguments, and also
improves (I think) some of the error messages emitted when values of
the wrong type are passed to this function.
The read_var method takes two arguments, one a variable, which is
either a gdb.Symbol or a string, while the second, optional, argument
is always a gdb.Block.
I'm now using 'O!' as the format specifier for the second argument,
which allows the argument type to be checked early on. Currently, if
the second argument is of the wrong type then we get this error:
(gdb) python print(gdb.selected_frame().read_var("a1", "xxx"))
Traceback (most recent call last):
File "<string>", line 1, in <module>
RuntimeError: Second argument must be block.
Error while executing Python code.
(gdb)
After this commit, we now get an error like this:
(gdb) python print(gdb.selected_frame().read_var("a1", "xxx"))
Traceback (most recent call last):
File "<string>", line 1, in <module>
TypeError: argument 2 must be gdb.Block, not str
Error while executing Python code.
(gdb)
Changes are:
1. Exception type is TypeError not RuntimeError, this is unfortunate
as user code _could_ be relying on this, but I think the improvement
is worth the risk, user code relying on the exact exception type is
likely to be pretty rare,
2. New error message gives argument position and expected argument
type, as well as the type that was passed.
If the first argument, the variable, has the wrong type then the
previous exception was already a TypeError, however, I've updated the
text of the exception to more closely match the "standard" error
message we see above. If the first argument has the wrong type then
before this commit we saw this:
(gdb) python print(gdb.selected_frame().read_var(123))
Traceback (most recent call last):
File "<string>", line 1, in <module>
TypeError: Argument must be a symbol or string.
Error while executing Python code.
(gdb)
And after we see this:
(gdb) python print(gdb.selected_frame().read_var(123))
Traceback (most recent call last):
File "<string>", line 1, in <module>
TypeError: argument 1 must be gdb.Symbol or str, not int
Error while executing Python code.
(gdb)
For existing code that doesn't use named arguments and doesn't rely on
exceptions, there will be no changes after this commit.
Reviewed-By: Tom Tromey <tom@tromey.com>
2023-03-30 11:21:32 +01:00
|
|
|
|
frapy_read_var (PyObject *self, PyObject *args, PyObject *kw)
|
2009-03-30 19:54:33 +00:00
|
|
|
|
{
|
2022-07-25 14:06:35 -03:00
|
|
|
|
frame_info_ptr frame;
|
2010-02-28 21:56:50 +00:00
|
|
|
|
PyObject *sym_obj, *block_obj = NULL;
|
2009-03-30 19:54:33 +00:00
|
|
|
|
struct symbol *var = NULL; /* gcc-4.3.2 false warning. */
|
2015-02-05 17:00:06 +01:00
|
|
|
|
const struct block *block = NULL;
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
gdb/python: allow Frame.read_var to accept named arguments
This commit allows Frame.read_var to accept named arguments, and also
improves (I think) some of the error messages emitted when values of
the wrong type are passed to this function.
The read_var method takes two arguments, one a variable, which is
either a gdb.Symbol or a string, while the second, optional, argument
is always a gdb.Block.
I'm now using 'O!' as the format specifier for the second argument,
which allows the argument type to be checked early on. Currently, if
the second argument is of the wrong type then we get this error:
(gdb) python print(gdb.selected_frame().read_var("a1", "xxx"))
Traceback (most recent call last):
File "<string>", line 1, in <module>
RuntimeError: Second argument must be block.
Error while executing Python code.
(gdb)
After this commit, we now get an error like this:
(gdb) python print(gdb.selected_frame().read_var("a1", "xxx"))
Traceback (most recent call last):
File "<string>", line 1, in <module>
TypeError: argument 2 must be gdb.Block, not str
Error while executing Python code.
(gdb)
Changes are:
1. Exception type is TypeError not RuntimeError, this is unfortunate
as user code _could_ be relying on this, but I think the improvement
is worth the risk, user code relying on the exact exception type is
likely to be pretty rare,
2. New error message gives argument position and expected argument
type, as well as the type that was passed.
If the first argument, the variable, has the wrong type then the
previous exception was already a TypeError, however, I've updated the
text of the exception to more closely match the "standard" error
message we see above. If the first argument has the wrong type then
before this commit we saw this:
(gdb) python print(gdb.selected_frame().read_var(123))
Traceback (most recent call last):
File "<string>", line 1, in <module>
TypeError: Argument must be a symbol or string.
Error while executing Python code.
(gdb)
And after we see this:
(gdb) python print(gdb.selected_frame().read_var(123))
Traceback (most recent call last):
File "<string>", line 1, in <module>
TypeError: argument 1 must be gdb.Symbol or str, not int
Error while executing Python code.
(gdb)
For existing code that doesn't use named arguments and doesn't rely on
exceptions, there will be no changes after this commit.
Reviewed-By: Tom Tromey <tom@tromey.com>
2023-03-30 11:21:32 +01:00
|
|
|
|
static const char *keywords[] = { "variable", "block", nullptr };
|
|
|
|
|
|
if (!gdb_PyArg_ParseTupleAndKeywords (args, kw, "O|O!", keywords,
|
|
|
|
|
|
&sym_obj, &block_object_type,
|
|
|
|
|
|
&block_obj))
|
|
|
|
|
|
return nullptr;
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
Tom Tromey <tromey@redhat.com>
Thiago Jung Bauermann <bauerman@br.ibm.com>
* python/python.c (_initialize_python): Call
gdbpy_initialize_symtabs, gdbpy_initialize_symbols and
gdbpy_initialize_blocks.
* python/python-internal.h: Declare struct symbol, block and
symtab_and_line. Declare block_object_type and
symbol_object_type
(gdbpy_lookup_symbol gdbpy_block_for_pc)
(symtab_and_line_to_sal_object, symtab_to_symtab_object)
(symbol_to_symbol_object, block_to_block_object)
(gdbpy_initialize_symtabs,gdbpy_initialize_symbols)
(gdbpy_initialize_blocks ): Declare.
* python/py-frame.c (frapy_block, frapy_function, frapy_find_sal)
(frapy_select): Add methods.
(frapy_read_var): Add symbol branch.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-symbol, py-symtab,
py-block.
(SUBDIR_PYTHON_SRCS): Likewise.
(py-symbol.o): New rule.
(py-symtab.o): Likewise.
(py-block.o): Likewise.
* python/py-symbol.c: New file.
* python/py-symtab.c: Likewise.
* python/py-block.c: Likewise.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* Makefile.in: Add py-block and py-symbol.
* gdb.python/py-symbol.exp: New File.
* gdb.python/py-symtab.exp: New File.
* gdb.python/py-block.exp: New File.
* gdb.python/py-symbol.c: New File.
* gdb.python/py-block.c: New File.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Frames In Python): Add block, find_sal, function
and select method descriptions.
(Python API): Add Blocks In Python, Symbols in Python and Symbol
Tables in Python to menu.
(Blocks In Python): New node.
(Symbols In Python): New node.
(Symbol Tables in Python): New node.
2010-02-24 21:18:28 +00:00
|
|
|
|
if (PyObject_TypeCheck (sym_obj, &symbol_object_type))
|
|
|
|
|
|
var = symbol_object_to_symbol (sym_obj);
|
|
|
|
|
|
else if (gdbpy_is_string (sym_obj))
|
2009-03-30 19:54:33 +00:00
|
|
|
|
{
|
Use unique_xmalloc_ptr in Python code
This changes some utility functions in the Python code to return
unique_xmalloc_ptr, and then fixes up the callers.
I chose unique_xmalloc_ptr rather than std::string because at a few
call points the xmalloc'd string is released and ownership transferred
elsewhere.
This patch found a few existing memory leaks. For example,
py-unwind.c called gdbpy_obj_to_string but never freed the result.
Built and regression tested on the buildbot.
2016-11-09 Tom Tromey <tom@tromey.com>
* varobj.h (varobj_get_display_hint): Change return type.
* varobj.c (varobj_get_display_hint): Return unique_xmalloc_ptr.
(varobj_value_get_print_value): Update.
* python/python.c (gdbpy_before_prompt_hook, gdbpy_print_stack)
(gdbpy_apply_type_printers): Update.
* python/python-internal.h (unicode_to_target_string)
(python_string_to_target_string, python_string_to_host_string)
(gdbpy_obj_to_string, gdbpy_exception_to_string)
(gdbpy_get_display_hint): Change return types.
* python/py-varobj.c (py_varobj_iter_next): Update.
* python/py-value.c (valpy_getitem, convert_value_from_python):
Update.
* python/py-utils.c (unicode_to_encoded_string)
(unicode_to_target_string, python_string_to_target_string)
(python_string_to_host_string, gdbpy_obj_to_string)
(gdbpy_exception_to_string): Return unique_xmalloc_ptr.
* python/py-unwind.c (pyuw_parse_register_id): Update.
* python/py-type.c (typy_getitem): Update.
* python/py-prettyprint.c (gdbpy_get_display_hint)
(print_stack_unless_memory_error, print_children)
(gdbpy_apply_val_pretty_printer): Update.
* python/py-param.c (set_parameter_value): Update.
(get_doc_string, call_doc_function): Return unique_xmalloc_ptr.
(get_set_value, get_show_value, compute_enum_values, parmpy_init):
Update.
* python/py-infthread.c (thpy_set_name): Update.
* python/py-function.c (fnpy_call, fnpy_init): Update.
* python/py-framefilter.c (extract_sym): Change "name" to
unique_xmalloc_ptr.
(enumerate_args, enumerate_locals): Update.
(py_print_frame): Use unique_xmalloc_ptr.
* python/py-frame.c (frapy_read_var): Update. Remove cleanup.
* python/py-cmd.c (cmdpy_function, cmdpy_completer, cmdpy_init):
Update.
* python/py-breakpoint.c (bppy_set_condition): Use
unique_xmalloc_ptr.
(bppy_init): Likewise. Remove cleanup.
(local_setattro): Update.
* mi/mi-cmd-var.c (print_varobj, mi_cmd_var_list_children)
(varobj_update_one): Update.
2016-10-15 09:20:02 -06:00
|
|
|
|
gdb::unique_xmalloc_ptr<char>
|
|
|
|
|
|
var_name (python_string_to_target_string (sym_obj));
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
|
|
|
|
|
if (!var_name)
|
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
gdb/python: allow Frame.read_var to accept named arguments
This commit allows Frame.read_var to accept named arguments, and also
improves (I think) some of the error messages emitted when values of
the wrong type are passed to this function.
The read_var method takes two arguments, one a variable, which is
either a gdb.Symbol or a string, while the second, optional, argument
is always a gdb.Block.
I'm now using 'O!' as the format specifier for the second argument,
which allows the argument type to be checked early on. Currently, if
the second argument is of the wrong type then we get this error:
(gdb) python print(gdb.selected_frame().read_var("a1", "xxx"))
Traceback (most recent call last):
File "<string>", line 1, in <module>
RuntimeError: Second argument must be block.
Error while executing Python code.
(gdb)
After this commit, we now get an error like this:
(gdb) python print(gdb.selected_frame().read_var("a1", "xxx"))
Traceback (most recent call last):
File "<string>", line 1, in <module>
TypeError: argument 2 must be gdb.Block, not str
Error while executing Python code.
(gdb)
Changes are:
1. Exception type is TypeError not RuntimeError, this is unfortunate
as user code _could_ be relying on this, but I think the improvement
is worth the risk, user code relying on the exact exception type is
likely to be pretty rare,
2. New error message gives argument position and expected argument
type, as well as the type that was passed.
If the first argument, the variable, has the wrong type then the
previous exception was already a TypeError, however, I've updated the
text of the exception to more closely match the "standard" error
message we see above. If the first argument has the wrong type then
before this commit we saw this:
(gdb) python print(gdb.selected_frame().read_var(123))
Traceback (most recent call last):
File "<string>", line 1, in <module>
TypeError: Argument must be a symbol or string.
Error while executing Python code.
(gdb)
And after we see this:
(gdb) python print(gdb.selected_frame().read_var(123))
Traceback (most recent call last):
File "<string>", line 1, in <module>
TypeError: argument 1 must be gdb.Symbol or str, not int
Error while executing Python code.
(gdb)
For existing code that doesn't use named arguments and doesn't rely on
exceptions, there will be no changes after this commit.
Reviewed-By: Tom Tromey <tom@tromey.com>
2023-03-30 11:21:32 +01:00
|
|
|
|
if (block_obj != nullptr)
|
2010-02-28 21:56:50 +00:00
|
|
|
|
{
|
gdb/python: allow Frame.read_var to accept named arguments
This commit allows Frame.read_var to accept named arguments, and also
improves (I think) some of the error messages emitted when values of
the wrong type are passed to this function.
The read_var method takes two arguments, one a variable, which is
either a gdb.Symbol or a string, while the second, optional, argument
is always a gdb.Block.
I'm now using 'O!' as the format specifier for the second argument,
which allows the argument type to be checked early on. Currently, if
the second argument is of the wrong type then we get this error:
(gdb) python print(gdb.selected_frame().read_var("a1", "xxx"))
Traceback (most recent call last):
File "<string>", line 1, in <module>
RuntimeError: Second argument must be block.
Error while executing Python code.
(gdb)
After this commit, we now get an error like this:
(gdb) python print(gdb.selected_frame().read_var("a1", "xxx"))
Traceback (most recent call last):
File "<string>", line 1, in <module>
TypeError: argument 2 must be gdb.Block, not str
Error while executing Python code.
(gdb)
Changes are:
1. Exception type is TypeError not RuntimeError, this is unfortunate
as user code _could_ be relying on this, but I think the improvement
is worth the risk, user code relying on the exact exception type is
likely to be pretty rare,
2. New error message gives argument position and expected argument
type, as well as the type that was passed.
If the first argument, the variable, has the wrong type then the
previous exception was already a TypeError, however, I've updated the
text of the exception to more closely match the "standard" error
message we see above. If the first argument has the wrong type then
before this commit we saw this:
(gdb) python print(gdb.selected_frame().read_var(123))
Traceback (most recent call last):
File "<string>", line 1, in <module>
TypeError: Argument must be a symbol or string.
Error while executing Python code.
(gdb)
And after we see this:
(gdb) python print(gdb.selected_frame().read_var(123))
Traceback (most recent call last):
File "<string>", line 1, in <module>
TypeError: argument 1 must be gdb.Symbol or str, not int
Error while executing Python code.
(gdb)
For existing code that doesn't use named arguments and doesn't rely on
exceptions, there will be no changes after this commit.
Reviewed-By: Tom Tromey <tom@tromey.com>
2023-03-30 11:21:32 +01:00
|
|
|
|
/* This call should only fail if the type of BLOCK_OBJ is wrong,
|
|
|
|
|
|
and we ensure the type is correct when we parse the arguments,
|
|
|
|
|
|
so we can just assert the return value is not nullptr. */
|
2010-02-28 21:56:50 +00:00
|
|
|
|
block = block_object_to_block (block_obj);
|
gdb/python: allow Frame.read_var to accept named arguments
This commit allows Frame.read_var to accept named arguments, and also
improves (I think) some of the error messages emitted when values of
the wrong type are passed to this function.
The read_var method takes two arguments, one a variable, which is
either a gdb.Symbol or a string, while the second, optional, argument
is always a gdb.Block.
I'm now using 'O!' as the format specifier for the second argument,
which allows the argument type to be checked early on. Currently, if
the second argument is of the wrong type then we get this error:
(gdb) python print(gdb.selected_frame().read_var("a1", "xxx"))
Traceback (most recent call last):
File "<string>", line 1, in <module>
RuntimeError: Second argument must be block.
Error while executing Python code.
(gdb)
After this commit, we now get an error like this:
(gdb) python print(gdb.selected_frame().read_var("a1", "xxx"))
Traceback (most recent call last):
File "<string>", line 1, in <module>
TypeError: argument 2 must be gdb.Block, not str
Error while executing Python code.
(gdb)
Changes are:
1. Exception type is TypeError not RuntimeError, this is unfortunate
as user code _could_ be relying on this, but I think the improvement
is worth the risk, user code relying on the exact exception type is
likely to be pretty rare,
2. New error message gives argument position and expected argument
type, as well as the type that was passed.
If the first argument, the variable, has the wrong type then the
previous exception was already a TypeError, however, I've updated the
text of the exception to more closely match the "standard" error
message we see above. If the first argument has the wrong type then
before this commit we saw this:
(gdb) python print(gdb.selected_frame().read_var(123))
Traceback (most recent call last):
File "<string>", line 1, in <module>
TypeError: Argument must be a symbol or string.
Error while executing Python code.
(gdb)
And after we see this:
(gdb) python print(gdb.selected_frame().read_var(123))
Traceback (most recent call last):
File "<string>", line 1, in <module>
TypeError: argument 1 must be gdb.Symbol or str, not int
Error while executing Python code.
(gdb)
For existing code that doesn't use named arguments and doesn't rely on
exceptions, there will be no changes after this commit.
Reviewed-By: Tom Tromey <tom@tromey.com>
2023-03-30 11:21:32 +01:00
|
|
|
|
gdb_assert (block != nullptr);
|
2010-02-28 21:56:50 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
2019-04-03 16:02:42 -06:00
|
|
|
|
try
|
2009-03-30 19:54:33 +00:00
|
|
|
|
{
|
2015-02-05 17:00:06 +01:00
|
|
|
|
struct block_symbol lookup_sym;
|
2011-12-23 17:06:16 +00:00
|
|
|
|
FRAPY_REQUIRE_VALID (self, frame);
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
2010-02-28 21:56:50 +00:00
|
|
|
|
if (!block)
|
2011-04-17 14:14:23 +00:00
|
|
|
|
block = get_frame_block (frame, NULL);
|
2023-03-30 23:00:26 -06:00
|
|
|
|
lookup_sym = lookup_symbol (var_name.get (), block,
|
|
|
|
|
|
SEARCH_VFT, nullptr);
|
2015-02-05 17:00:06 +01:00
|
|
|
|
var = lookup_sym.symbol;
|
|
|
|
|
|
block = lookup_sym.block;
|
2009-03-30 19:54:33 +00:00
|
|
|
|
}
|
2019-04-03 15:59:07 -06:00
|
|
|
|
catch (const gdb_exception &except)
|
2013-05-30 17:16:05 +00:00
|
|
|
|
{
|
2024-09-24 13:06:32 +02:00
|
|
|
|
return gdbpy_handle_gdb_exception (nullptr, except);
|
2013-05-30 17:16:05 +00:00
|
|
|
|
}
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
|
|
|
|
|
if (!var)
|
|
|
|
|
|
{
|
|
|
|
|
|
PyErr_Format (PyExc_ValueError,
|
Use unique_xmalloc_ptr in Python code
This changes some utility functions in the Python code to return
unique_xmalloc_ptr, and then fixes up the callers.
I chose unique_xmalloc_ptr rather than std::string because at a few
call points the xmalloc'd string is released and ownership transferred
elsewhere.
This patch found a few existing memory leaks. For example,
py-unwind.c called gdbpy_obj_to_string but never freed the result.
Built and regression tested on the buildbot.
2016-11-09 Tom Tromey <tom@tromey.com>
* varobj.h (varobj_get_display_hint): Change return type.
* varobj.c (varobj_get_display_hint): Return unique_xmalloc_ptr.
(varobj_value_get_print_value): Update.
* python/python.c (gdbpy_before_prompt_hook, gdbpy_print_stack)
(gdbpy_apply_type_printers): Update.
* python/python-internal.h (unicode_to_target_string)
(python_string_to_target_string, python_string_to_host_string)
(gdbpy_obj_to_string, gdbpy_exception_to_string)
(gdbpy_get_display_hint): Change return types.
* python/py-varobj.c (py_varobj_iter_next): Update.
* python/py-value.c (valpy_getitem, convert_value_from_python):
Update.
* python/py-utils.c (unicode_to_encoded_string)
(unicode_to_target_string, python_string_to_target_string)
(python_string_to_host_string, gdbpy_obj_to_string)
(gdbpy_exception_to_string): Return unique_xmalloc_ptr.
* python/py-unwind.c (pyuw_parse_register_id): Update.
* python/py-type.c (typy_getitem): Update.
* python/py-prettyprint.c (gdbpy_get_display_hint)
(print_stack_unless_memory_error, print_children)
(gdbpy_apply_val_pretty_printer): Update.
* python/py-param.c (set_parameter_value): Update.
(get_doc_string, call_doc_function): Return unique_xmalloc_ptr.
(get_set_value, get_show_value, compute_enum_values, parmpy_init):
Update.
* python/py-infthread.c (thpy_set_name): Update.
* python/py-function.c (fnpy_call, fnpy_init): Update.
* python/py-framefilter.c (extract_sym): Change "name" to
unique_xmalloc_ptr.
(enumerate_args, enumerate_locals): Update.
(py_print_frame): Use unique_xmalloc_ptr.
* python/py-frame.c (frapy_read_var): Update. Remove cleanup.
* python/py-cmd.c (cmdpy_function, cmdpy_completer, cmdpy_init):
Update.
* python/py-breakpoint.c (bppy_set_condition): Use
unique_xmalloc_ptr.
(bppy_init): Likewise. Remove cleanup.
(local_setattro): Update.
* mi/mi-cmd-var.c (print_varobj, mi_cmd_var_list_children)
(varobj_update_one): Update.
2016-10-15 09:20:02 -06:00
|
|
|
|
_("Variable '%s' not found."), var_name.get ());
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
|
|
}
|
|
|
|
|
|
}
|
|
|
|
|
|
else
|
|
|
|
|
|
{
|
gdb/python: allow Frame.read_var to accept named arguments
This commit allows Frame.read_var to accept named arguments, and also
improves (I think) some of the error messages emitted when values of
the wrong type are passed to this function.
The read_var method takes two arguments, one a variable, which is
either a gdb.Symbol or a string, while the second, optional, argument
is always a gdb.Block.
I'm now using 'O!' as the format specifier for the second argument,
which allows the argument type to be checked early on. Currently, if
the second argument is of the wrong type then we get this error:
(gdb) python print(gdb.selected_frame().read_var("a1", "xxx"))
Traceback (most recent call last):
File "<string>", line 1, in <module>
RuntimeError: Second argument must be block.
Error while executing Python code.
(gdb)
After this commit, we now get an error like this:
(gdb) python print(gdb.selected_frame().read_var("a1", "xxx"))
Traceback (most recent call last):
File "<string>", line 1, in <module>
TypeError: argument 2 must be gdb.Block, not str
Error while executing Python code.
(gdb)
Changes are:
1. Exception type is TypeError not RuntimeError, this is unfortunate
as user code _could_ be relying on this, but I think the improvement
is worth the risk, user code relying on the exact exception type is
likely to be pretty rare,
2. New error message gives argument position and expected argument
type, as well as the type that was passed.
If the first argument, the variable, has the wrong type then the
previous exception was already a TypeError, however, I've updated the
text of the exception to more closely match the "standard" error
message we see above. If the first argument has the wrong type then
before this commit we saw this:
(gdb) python print(gdb.selected_frame().read_var(123))
Traceback (most recent call last):
File "<string>", line 1, in <module>
TypeError: Argument must be a symbol or string.
Error while executing Python code.
(gdb)
And after we see this:
(gdb) python print(gdb.selected_frame().read_var(123))
Traceback (most recent call last):
File "<string>", line 1, in <module>
TypeError: argument 1 must be gdb.Symbol or str, not int
Error while executing Python code.
(gdb)
For existing code that doesn't use named arguments and doesn't rely on
exceptions, there will be no changes after this commit.
Reviewed-By: Tom Tromey <tom@tromey.com>
2023-03-30 11:21:32 +01:00
|
|
|
|
PyErr_Format (PyExc_TypeError,
|
|
|
|
|
|
_("argument 1 must be gdb.Symbol or str, not %s"),
|
2026-05-26 11:46:29 +01:00
|
|
|
|
gdbpy_py_obj_tp_name (sym_obj).c_str ());
|
2009-03-30 19:54:33 +00:00
|
|
|
|
return NULL;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2026-02-20 13:02:00 -07:00
|
|
|
|
gdbpy_ref<> result;
|
2019-04-03 16:02:42 -06:00
|
|
|
|
try
|
2009-03-30 19:54:33 +00:00
|
|
|
|
{
|
2011-12-23 17:06:16 +00:00
|
|
|
|
FRAPY_REQUIRE_VALID (self, frame);
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
Fix value chain use-after-free
Hannes filed a bug showing a crash, where a pretty-printer written in
Python could cause a use-after-free. He sent a patch, but I thought a
different approach was needed.
In a much earlier patch (see bug #12533), we changed the Python code
to release new values from the value chain when constructing a
gdb.Value. The rationale for this is that if you write a command that
does a lot of computations in a loop, all the values will be kept live
by the value chain, resulting in gdb using a large amount of memory.
However, suppose a value is passed to Python from some code in gdb
that needs to use the value after the call into Python. In this
scenario, value_to_value_object will still release the value -- and
because gdb code doesn't generally keep strong references to values (a
consequence of the ancient decision to use the value chain to avoid
memory management), this will result in a use-after-free.
This scenario can happen, as it turns out, when a value is passed to
Python for pretty-printing. Now, normally this route boxes the value
via value_to_value_object_no_release, avoiding the problematic release
from the value chain. However, if you then call Value.cast, the
underlying value API might return the same value, when is then
released from the chain.
This patch fixes the problem by changing how value boxing is done.
value_to_value_object no longer removes a value from the chain.
Instead, every spot in gdb that might construct new values uses a
scoped_value_mark to ensure that the requirements of bug #12533 are
met. And, because incoming values aren't ever released from the chain
(the Value.cast one comes earlier on the chain than the
scoped_value_mark), the bug can no longer occur. (Note that many
spots in the Python layer already take this approach, so not many
places needed to be touched.)
In the future I think we should replace the use of raw "value *" with
value_ref_ptr pretty much everywhere. This will ensure lifetime
safety throughout gdb.
The test case in this patch comes from Hannes' original patch. I only
made a trivial ("require") change to it. However, while this fails
for him, I can't make it fail on this machine; nevertheless, he tried
my patch and reported the bug as being fixed.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30044
2023-02-08 13:59:36 -07:00
|
|
|
|
scoped_value_mark free_values;
|
|
|
|
|
|
struct value *val = read_var_value (var, block, frame);
|
|
|
|
|
|
result = value_to_value_object (val);
|
2009-03-30 19:54:33 +00:00
|
|
|
|
}
|
2019-04-03 15:59:07 -06:00
|
|
|
|
catch (const gdb_exception &except)
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
{
|
2024-09-24 13:06:32 +02:00
|
|
|
|
return gdbpy_handle_gdb_exception (nullptr, except);
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
}
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
2026-02-20 13:02:00 -07:00
|
|
|
|
return result.release ();
|
2009-03-30 19:54:33 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
Tom Tromey <tromey@redhat.com>
Thiago Jung Bauermann <bauerman@br.ibm.com>
* python/python.c (_initialize_python): Call
gdbpy_initialize_symtabs, gdbpy_initialize_symbols and
gdbpy_initialize_blocks.
* python/python-internal.h: Declare struct symbol, block and
symtab_and_line. Declare block_object_type and
symbol_object_type
(gdbpy_lookup_symbol gdbpy_block_for_pc)
(symtab_and_line_to_sal_object, symtab_to_symtab_object)
(symbol_to_symbol_object, block_to_block_object)
(gdbpy_initialize_symtabs,gdbpy_initialize_symbols)
(gdbpy_initialize_blocks ): Declare.
* python/py-frame.c (frapy_block, frapy_function, frapy_find_sal)
(frapy_select): Add methods.
(frapy_read_var): Add symbol branch.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-symbol, py-symtab,
py-block.
(SUBDIR_PYTHON_SRCS): Likewise.
(py-symbol.o): New rule.
(py-symtab.o): Likewise.
(py-block.o): Likewise.
* python/py-symbol.c: New file.
* python/py-symtab.c: Likewise.
* python/py-block.c: Likewise.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* Makefile.in: Add py-block and py-symbol.
* gdb.python/py-symbol.exp: New File.
* gdb.python/py-symtab.exp: New File.
* gdb.python/py-block.exp: New File.
* gdb.python/py-symbol.c: New File.
* gdb.python/py-block.c: New File.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Frames In Python): Add block, find_sal, function
and select method descriptions.
(Python API): Add Blocks In Python, Symbols in Python and Symbol
Tables in Python to menu.
(Blocks In Python): New node.
(Symbols In Python): New node.
(Symbol Tables in Python): New node.
2010-02-24 21:18:28 +00:00
|
|
|
|
/* Select this frame. */
|
|
|
|
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
|
|
frapy_select (PyObject *self, PyObject *args)
|
|
|
|
|
|
{
|
2022-07-25 14:06:35 -03:00
|
|
|
|
frame_info_ptr fi;
|
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
Tom Tromey <tromey@redhat.com>
Thiago Jung Bauermann <bauerman@br.ibm.com>
* python/python.c (_initialize_python): Call
gdbpy_initialize_symtabs, gdbpy_initialize_symbols and
gdbpy_initialize_blocks.
* python/python-internal.h: Declare struct symbol, block and
symtab_and_line. Declare block_object_type and
symbol_object_type
(gdbpy_lookup_symbol gdbpy_block_for_pc)
(symtab_and_line_to_sal_object, symtab_to_symtab_object)
(symbol_to_symbol_object, block_to_block_object)
(gdbpy_initialize_symtabs,gdbpy_initialize_symbols)
(gdbpy_initialize_blocks ): Declare.
* python/py-frame.c (frapy_block, frapy_function, frapy_find_sal)
(frapy_select): Add methods.
(frapy_read_var): Add symbol branch.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-symbol, py-symtab,
py-block.
(SUBDIR_PYTHON_SRCS): Likewise.
(py-symbol.o): New rule.
(py-symtab.o): Likewise.
(py-block.o): Likewise.
* python/py-symbol.c: New file.
* python/py-symtab.c: Likewise.
* python/py-block.c: Likewise.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* Makefile.in: Add py-block and py-symbol.
* gdb.python/py-symbol.exp: New File.
* gdb.python/py-symtab.exp: New File.
* gdb.python/py-block.exp: New File.
* gdb.python/py-symbol.c: New File.
* gdb.python/py-block.c: New File.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Frames In Python): Add block, find_sal, function
and select method descriptions.
(Python API): Add Blocks In Python, Symbols in Python and Symbol
Tables in Python to menu.
(Blocks In Python): New node.
(Symbols In Python): New node.
(Symbol Tables in Python): New node.
2010-02-24 21:18:28 +00:00
|
|
|
|
|
2019-04-03 16:02:42 -06:00
|
|
|
|
try
|
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
Tom Tromey <tromey@redhat.com>
Thiago Jung Bauermann <bauerman@br.ibm.com>
* python/python.c (_initialize_python): Call
gdbpy_initialize_symtabs, gdbpy_initialize_symbols and
gdbpy_initialize_blocks.
* python/python-internal.h: Declare struct symbol, block and
symtab_and_line. Declare block_object_type and
symbol_object_type
(gdbpy_lookup_symbol gdbpy_block_for_pc)
(symtab_and_line_to_sal_object, symtab_to_symtab_object)
(symbol_to_symbol_object, block_to_block_object)
(gdbpy_initialize_symtabs,gdbpy_initialize_symbols)
(gdbpy_initialize_blocks ): Declare.
* python/py-frame.c (frapy_block, frapy_function, frapy_find_sal)
(frapy_select): Add methods.
(frapy_read_var): Add symbol branch.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-symbol, py-symtab,
py-block.
(SUBDIR_PYTHON_SRCS): Likewise.
(py-symbol.o): New rule.
(py-symtab.o): Likewise.
(py-block.o): Likewise.
* python/py-symbol.c: New file.
* python/py-symtab.c: Likewise.
* python/py-block.c: Likewise.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* Makefile.in: Add py-block and py-symbol.
* gdb.python/py-symbol.exp: New File.
* gdb.python/py-symtab.exp: New File.
* gdb.python/py-block.exp: New File.
* gdb.python/py-symbol.c: New File.
* gdb.python/py-block.c: New File.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Frames In Python): Add block, find_sal, function
and select method descriptions.
(Python API): Add Blocks In Python, Symbols in Python and Symbol
Tables in Python to menu.
(Blocks In Python): New node.
(Symbols In Python): New node.
(Symbol Tables in Python): New node.
2010-02-24 21:18:28 +00:00
|
|
|
|
{
|
2011-12-23 17:06:16 +00:00
|
|
|
|
FRAPY_REQUIRE_VALID (self, fi);
|
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
Tom Tromey <tromey@redhat.com>
Thiago Jung Bauermann <bauerman@br.ibm.com>
* python/python.c (_initialize_python): Call
gdbpy_initialize_symtabs, gdbpy_initialize_symbols and
gdbpy_initialize_blocks.
* python/python-internal.h: Declare struct symbol, block and
symtab_and_line. Declare block_object_type and
symbol_object_type
(gdbpy_lookup_symbol gdbpy_block_for_pc)
(symtab_and_line_to_sal_object, symtab_to_symtab_object)
(symbol_to_symbol_object, block_to_block_object)
(gdbpy_initialize_symtabs,gdbpy_initialize_symbols)
(gdbpy_initialize_blocks ): Declare.
* python/py-frame.c (frapy_block, frapy_function, frapy_find_sal)
(frapy_select): Add methods.
(frapy_read_var): Add symbol branch.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-symbol, py-symtab,
py-block.
(SUBDIR_PYTHON_SRCS): Likewise.
(py-symbol.o): New rule.
(py-symtab.o): Likewise.
(py-block.o): Likewise.
* python/py-symbol.c: New file.
* python/py-symtab.c: Likewise.
* python/py-block.c: Likewise.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* Makefile.in: Add py-block and py-symbol.
* gdb.python/py-symbol.exp: New File.
* gdb.python/py-symtab.exp: New File.
* gdb.python/py-block.exp: New File.
* gdb.python/py-symbol.c: New File.
* gdb.python/py-block.c: New File.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Frames In Python): Add block, find_sal, function
and select method descriptions.
(Python API): Add Blocks In Python, Symbols in Python and Symbol
Tables in Python to menu.
(Blocks In Python): New node.
(Symbols In Python): New node.
(Symbol Tables in Python): New node.
2010-02-24 21:18:28 +00:00
|
|
|
|
|
|
|
|
|
|
select_frame (fi);
|
|
|
|
|
|
}
|
2019-04-03 15:59:07 -06:00
|
|
|
|
catch (const gdb_exception &except)
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
{
|
2024-09-24 13:06:32 +02:00
|
|
|
|
return gdbpy_handle_gdb_exception (nullptr, except);
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
}
|
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
Tom Tromey <tromey@redhat.com>
Thiago Jung Bauermann <bauerman@br.ibm.com>
* python/python.c (_initialize_python): Call
gdbpy_initialize_symtabs, gdbpy_initialize_symbols and
gdbpy_initialize_blocks.
* python/python-internal.h: Declare struct symbol, block and
symtab_and_line. Declare block_object_type and
symbol_object_type
(gdbpy_lookup_symbol gdbpy_block_for_pc)
(symtab_and_line_to_sal_object, symtab_to_symtab_object)
(symbol_to_symbol_object, block_to_block_object)
(gdbpy_initialize_symtabs,gdbpy_initialize_symbols)
(gdbpy_initialize_blocks ): Declare.
* python/py-frame.c (frapy_block, frapy_function, frapy_find_sal)
(frapy_select): Add methods.
(frapy_read_var): Add symbol branch.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-symbol, py-symtab,
py-block.
(SUBDIR_PYTHON_SRCS): Likewise.
(py-symbol.o): New rule.
(py-symtab.o): Likewise.
(py-block.o): Likewise.
* python/py-symbol.c: New file.
* python/py-symtab.c: Likewise.
* python/py-block.c: Likewise.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* Makefile.in: Add py-block and py-symbol.
* gdb.python/py-symbol.exp: New File.
* gdb.python/py-symtab.exp: New File.
* gdb.python/py-block.exp: New File.
* gdb.python/py-symbol.c: New File.
* gdb.python/py-block.c: New File.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Frames In Python): Add block, find_sal, function
and select method descriptions.
(Python API): Add Blocks In Python, Symbols in Python and Symbol
Tables in Python to menu.
(Blocks In Python): New node.
(Symbols In Python): New node.
(Symbol Tables in Python): New node.
2010-02-24 21:18:28 +00:00
|
|
|
|
|
2026-05-15 21:38:12 +02:00
|
|
|
|
return py_none ().release ();
|
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
Tom Tromey <tromey@redhat.com>
Thiago Jung Bauermann <bauerman@br.ibm.com>
* python/python.c (_initialize_python): Call
gdbpy_initialize_symtabs, gdbpy_initialize_symbols and
gdbpy_initialize_blocks.
* python/python-internal.h: Declare struct symbol, block and
symtab_and_line. Declare block_object_type and
symbol_object_type
(gdbpy_lookup_symbol gdbpy_block_for_pc)
(symtab_and_line_to_sal_object, symtab_to_symtab_object)
(symbol_to_symbol_object, block_to_block_object)
(gdbpy_initialize_symtabs,gdbpy_initialize_symbols)
(gdbpy_initialize_blocks ): Declare.
* python/py-frame.c (frapy_block, frapy_function, frapy_find_sal)
(frapy_select): Add methods.
(frapy_read_var): Add symbol branch.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-symbol, py-symtab,
py-block.
(SUBDIR_PYTHON_SRCS): Likewise.
(py-symbol.o): New rule.
(py-symtab.o): Likewise.
(py-block.o): Likewise.
* python/py-symbol.c: New file.
* python/py-symtab.c: Likewise.
* python/py-block.c: Likewise.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* Makefile.in: Add py-block and py-symbol.
* gdb.python/py-symbol.exp: New File.
* gdb.python/py-symtab.exp: New File.
* gdb.python/py-block.exp: New File.
* gdb.python/py-symbol.c: New File.
* gdb.python/py-block.c: New File.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Frames In Python): Add block, find_sal, function
and select method descriptions.
(Python API): Add Blocks In Python, Symbols in Python and Symbol
Tables in Python to menu.
(Blocks In Python): New node.
(Symbols In Python): New node.
(Symbol Tables in Python): New node.
2010-02-24 21:18:28 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
2021-05-26 22:01:59 +01:00
|
|
|
|
/* The stack frame level for this frame. */
|
|
|
|
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
|
|
frapy_level (PyObject *self, PyObject *args)
|
|
|
|
|
|
{
|
2022-07-25 14:06:35 -03:00
|
|
|
|
frame_info_ptr fi;
|
2021-05-26 22:01:59 +01:00
|
|
|
|
|
|
|
|
|
|
try
|
|
|
|
|
|
{
|
|
|
|
|
|
FRAPY_REQUIRE_VALID (self, fi);
|
|
|
|
|
|
|
|
|
|
|
|
return gdb_py_object_from_longest (frame_relative_level (fi)).release ();
|
|
|
|
|
|
}
|
|
|
|
|
|
catch (const gdb_exception &except)
|
|
|
|
|
|
{
|
2024-09-24 13:06:32 +02:00
|
|
|
|
return gdbpy_handle_gdb_exception (nullptr, except);
|
2021-05-26 22:01:59 +01:00
|
|
|
|
}
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2022-05-24 10:15:17 -06:00
|
|
|
|
/* The language for this frame. */
|
|
|
|
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
|
|
frapy_language (PyObject *self, PyObject *args)
|
|
|
|
|
|
{
|
|
|
|
|
|
try
|
|
|
|
|
|
{
|
2022-07-25 14:06:35 -03:00
|
|
|
|
frame_info_ptr fi;
|
2022-05-24 10:15:17 -06:00
|
|
|
|
FRAPY_REQUIRE_VALID (self, fi);
|
|
|
|
|
|
|
|
|
|
|
|
enum language lang = get_frame_language (fi);
|
|
|
|
|
|
const language_defn *lang_def = language_def (lang);
|
|
|
|
|
|
|
|
|
|
|
|
return host_string_to_python_string (lang_def->name ()).release ();
|
|
|
|
|
|
}
|
|
|
|
|
|
catch (const gdb_exception &except)
|
|
|
|
|
|
{
|
2024-09-24 13:06:32 +02:00
|
|
|
|
return gdbpy_handle_gdb_exception (nullptr, except);
|
2022-05-24 10:15:17 -06:00
|
|
|
|
}
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2023-10-24 08:05:06 -06:00
|
|
|
|
/* The static link for this frame. */
|
|
|
|
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
|
|
frapy_static_link (PyObject *self, PyObject *args)
|
|
|
|
|
|
{
|
|
|
|
|
|
frame_info_ptr link;
|
|
|
|
|
|
|
|
|
|
|
|
try
|
|
|
|
|
|
{
|
|
|
|
|
|
FRAPY_REQUIRE_VALID (self, link);
|
|
|
|
|
|
|
|
|
|
|
|
link = frame_follow_static_link (link);
|
|
|
|
|
|
}
|
|
|
|
|
|
catch (const gdb_exception &except)
|
|
|
|
|
|
{
|
2024-09-24 13:06:32 +02:00
|
|
|
|
return gdbpy_handle_gdb_exception (nullptr, except);
|
2023-10-24 08:05:06 -06:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
if (link == nullptr)
|
2026-05-15 21:38:12 +02:00
|
|
|
|
return py_none ().release ();
|
2023-10-24 08:05:06 -06:00
|
|
|
|
|
2026-02-20 13:06:56 -07:00
|
|
|
|
return frame_info_to_frame_object (link).release ();
|
2023-10-24 08:05:06 -06:00
|
|
|
|
}
|
|
|
|
|
|
|
2011-01-06 21:10:53 +00:00
|
|
|
|
/* Implementation of gdb.newest_frame () -> gdb.Frame.
|
|
|
|
|
|
Returns the newest frame object. */
|
|
|
|
|
|
|
|
|
|
|
|
PyObject *
|
|
|
|
|
|
gdbpy_newest_frame (PyObject *self, PyObject *args)
|
|
|
|
|
|
{
|
2022-07-25 14:06:35 -03:00
|
|
|
|
frame_info_ptr frame = NULL;
|
2011-01-06 21:10:53 +00:00
|
|
|
|
|
2019-04-03 16:02:42 -06:00
|
|
|
|
try
|
2011-01-06 21:10:53 +00:00
|
|
|
|
{
|
|
|
|
|
|
frame = get_current_frame ();
|
|
|
|
|
|
}
|
2019-04-03 15:59:07 -06:00
|
|
|
|
catch (const gdb_exception &except)
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
{
|
2024-09-24 13:06:32 +02:00
|
|
|
|
return gdbpy_handle_gdb_exception (nullptr, except);
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
}
|
2011-01-06 21:10:53 +00:00
|
|
|
|
|
2026-02-20 13:06:56 -07:00
|
|
|
|
return frame_info_to_frame_object (frame).release ();
|
2011-01-06 21:10:53 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
2009-03-30 19:54:33 +00:00
|
|
|
|
/* Implementation of gdb.selected_frame () -> gdb.Frame.
|
|
|
|
|
|
Returns the selected frame object. */
|
|
|
|
|
|
|
|
|
|
|
|
PyObject *
|
|
|
|
|
|
gdbpy_selected_frame (PyObject *self, PyObject *args)
|
|
|
|
|
|
{
|
2022-07-25 14:06:35 -03:00
|
|
|
|
frame_info_ptr frame = NULL;
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
2019-04-03 16:02:42 -06:00
|
|
|
|
try
|
2009-03-30 19:54:33 +00:00
|
|
|
|
{
|
|
|
|
|
|
frame = get_selected_frame ("No frame is currently selected.");
|
|
|
|
|
|
}
|
2019-04-03 15:59:07 -06:00
|
|
|
|
catch (const gdb_exception &except)
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
{
|
2024-09-24 13:06:32 +02:00
|
|
|
|
return gdbpy_handle_gdb_exception (nullptr, except);
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
}
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
2026-02-20 13:06:56 -07:00
|
|
|
|
return frame_info_to_frame_object (frame).release ();
|
2009-03-30 19:54:33 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* Implementation of gdb.stop_reason_string (Integer) -> String.
|
|
|
|
|
|
Return a string explaining the unwind stop reason. */
|
|
|
|
|
|
|
|
|
|
|
|
PyObject *
|
|
|
|
|
|
gdbpy_frame_stop_reason_string (PyObject *self, PyObject *args)
|
|
|
|
|
|
{
|
|
|
|
|
|
int reason;
|
|
|
|
|
|
const char *str;
|
|
|
|
|
|
|
|
|
|
|
|
if (!PyArg_ParseTuple (args, "i", &reason))
|
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
2011-10-27 11:04:27 +00:00
|
|
|
|
if (reason < UNWIND_FIRST || reason > UNWIND_LAST)
|
2009-03-30 19:54:33 +00:00
|
|
|
|
{
|
2013-11-29 12:00:47 -08:00
|
|
|
|
PyErr_SetString (PyExc_ValueError,
|
2010-04-14 13:18:55 +00:00
|
|
|
|
_("Invalid frame stop reason."));
|
2009-03-30 19:54:33 +00:00
|
|
|
|
return NULL;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2015-08-06 17:21:41 -04:00
|
|
|
|
str = unwind_stop_reason_to_string ((enum unwind_stop_reason) reason);
|
2009-03-30 19:54:33 +00:00
|
|
|
|
return PyUnicode_Decode (str, strlen (str), host_charset (), NULL);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* Implements the equality comparison for Frame objects.
|
|
|
|
|
|
All other comparison operators will throw a TypeError Python exception,
|
|
|
|
|
|
as they aren't valid for frames. */
|
|
|
|
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
|
|
frapy_richcompare (PyObject *self, PyObject *other, int op)
|
|
|
|
|
|
{
|
2009-04-13 20:54:59 +00:00
|
|
|
|
int result;
|
|
|
|
|
|
|
|
|
|
|
|
if (!PyObject_TypeCheck (other, &frame_object_type)
|
|
|
|
|
|
|| (op != Py_EQ && op != Py_NE))
|
2026-05-15 21:38:12 +02:00
|
|
|
|
return py_notimplemented ().release ();
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
2020-12-18 18:23:41 +01:00
|
|
|
|
frame_object *self_frame = (frame_object *) self;
|
|
|
|
|
|
frame_object *other_frame = (frame_object *) other;
|
|
|
|
|
|
|
gdb/python: remove frame_object::frame_id_is_next as unnecessary
Remove the frame_object::frame_id_is_next field. This has been part
of how Python handles frames since this code was first added in commit
f8f6f20b6e37e6d219940fcad58b1f66124d11c1 back in 2009. The motivation
for this field can be found in a couple of comments, there's this one
on frame_id_is_next:
/* Marks that the FRAME_ID member actually holds the ID of the frame next
to this, and not this frames' ID itself. This is a hack to permit Python
frame objects which represent invalid frames (i.e., the last frame_info
in a corrupt stack). The problem arises from the fact that this code
relies on FRAME_ID to uniquely identify a frame, which is not always true
for the last "frame" in a corrupt stack (it can have a null ID, or the same
ID as the previous frame). Whenever get_prev_frame returns NULL, we
record the frame_id of the next frame and set FRAME_ID_IS_NEXT to 1. */
And this one in frame_info_to_frame_object:
/* Try to get the previous frame, to determine if this is the last frame
in a corrupt stack. If so, we need to store the frame_id of the next
frame and not of this one (which is possibly invalid). */
This field is dealing with a problem that was present in older
versions of GDB where not every stack frame had a valid frame-id, if
the stack was corrupted in some way then the last frame might have an
invalid frame-id. However, that is no longer the case. With current
GDB there is a promise that every frame has a valid frame-id. I don't
have a single commit to point to where this became the reality, but it
is my understanding of current GDB.
As an example, the frame-id of every frame (except #0) is computed as
the frame is created, any frames with a duplicate frame-id, or any
errors during computation of the frame-id, and the new frame is
discarded.
Additionally, our frame_info_ptr::reinflate mechanism relies on unique
and valid frame-ids.
The problem with the existing code is that the last frame in a
corrupted stack will hold the frame-id of the next frame, that is, the
more inner frame. This means we have two frames holding the same
frame-id, and the only difference is the frame_id_is_next flag.
However, the frapy_str function, which prints a string representation
of the frame, doesn't take frame_id_is_next into account, so printing
the last two frames in a corrupted stack, will print the same
frame-id.
We could fix this in frapy_str and also frapy_repr by checking the
frame_id_is_next flag and then fetching the previous frame-id, but
this would still assume that the previous frame has a valid-id, so we
might as well just drop the frame_id_is_next flag and make everything
simpler.
There's a new test which exposes the incorrectly printed frame-id
problem.
While testing I needed to "fix" the results for two existing tests.
In frame_info_to_frame_object, in order to figure out if we should use
the next frame, we called get_prev_frame. This would cause GDB to
always unwind 1 extra level of the stack.
What this means is that, if there is an error, or some diagnostic
output, when unwinding frame #1, then this will show up when trying to
access frame #0 via the Python API as frame_info_to_frame_object on
frame #0 would call get_prev_frame, which would then unwind frame #1.
After this commit this is no longer the case. We only see
output (either errors, or diagnostic output) associated with frame #1
when we actually try to unwind to frame #1. The two tests that needed
updating were expecting output associated with frame #1 while printing
frame #0. This is now fixed and the output for frame #1 occurs later
on. I think this is an improvement.
2026-06-01 16:07:49 +01:00
|
|
|
|
if (self_frame->frame_id == other_frame->frame_id)
|
2009-04-13 20:54:59 +00:00
|
|
|
|
result = Py_EQ;
|
|
|
|
|
|
else
|
|
|
|
|
|
result = Py_NE;
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
2009-04-13 20:54:59 +00:00
|
|
|
|
if (op == result)
|
2026-05-15 21:38:12 +02:00
|
|
|
|
return py_true ().release ();
|
|
|
|
|
|
return py_false ().release ();
|
2009-03-30 19:54:33 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* Sets up the Frame API in the gdb module. */
|
|
|
|
|
|
|
2025-10-21 10:00:20 -06:00
|
|
|
|
static int
|
|
|
|
|
|
gdbpy_initialize_frames ()
|
2009-03-30 19:54:33 +00:00
|
|
|
|
{
|
2011-08-05 14:24:10 +00:00
|
|
|
|
frame_object_type.tp_new = PyType_GenericNew;
|
2024-09-11 10:35:20 -06:00
|
|
|
|
if (gdbpy_type_ready (&frame_object_type) < 0)
|
* python/py-arch.c (gdbpy_initialize_arch): Return 'int'.
Check errors.
* python/py-auto-load.c (gdbpy_initialize_auto_load): Return 'int'.
* python/py-block.c (gdbpy_initialize_blocks): Return 'int'.
Check errors.
* python/py-breakpoint.c (gdbpy_initialize_breakpoints): Return 'int'.
Check errors.
* python/py-cmd.c (gdbpy_initialize_commands): Return 'int'.
Check errors.
* python/py-event.c (gdbpy_initialize_event): Return 'int'.
Check errors.
* python/py-event.h (GDBPY_NEW_EVENT_TYPE): Change generated
init function to return 'int'.
* python/py-evtregistry.c (gdbpy_initialize_eventregistry):
Return 'int'. Check errors.
* python/py-evts.c (gdbpy_initialize_py_events): Return 'int'.
Check errors.
* python/py-finishbreakpoint.c (gdbpy_initialize_finishbreakpoints):
Return 'int'. Check errors.
* python/py-frame.c (gdbpy_initialize_frames): Return 'int'.
Check errors.
* python/py-function.c (gdbpy_initialize_functions): Return 'int'.
Check errors.
* python/py-gdb-readline.c (gdbpy_initialize_gdb_readline):
Check errors.
* python/py-inferior.c (gdbpy_initialize_inferior): Return 'int'.
Check errors.
* python/py-infthread.c (gdbpy_initialize_thread): Return 'int'.
Check errors.
* python/py-lazy-string.c (gdbpy_initialize_lazy_string): Return 'int'.
Check errors.
* python/py-objfile.c (gdbpy_initialize_objfile): Return 'int'.
Check errors.
* python/py-param.c (gdbpy_initialize_parameters): Return 'int'.
Check errors.
* python/py-progspace.c (gdbpy_initialize_pspace): Return 'int'.
Check errors.
* python/py-symbol.c (gdbpy_initialize_symbols): Return 'int'.
Check errors.
* python/py-symtab.c (gdbpy_initialize_symtabs): Return 'int'.
Check errors.
* python/py-type.c (gdbpy_initialize_types): Return 'int'.
Check errors.
* python/py-value.c (gdbpy_initialize_values): Return 'int'.
Check errors.
* python/python-internal.h (gdbpy_initialize_auto_load,
gdbpy_initialize_values, gdbpy_initialize_frames,
gdbpy_initialize_symtabs, gdbpy_initialize_commands,
gdbpy_initialize_symbols, gdbpy_initialize_symtabs,
gdbpy_initialize_blocks, gdbpy_initialize_types,
gdbpy_initialize_functions, gdbpy_initialize_pspace,
gdbpy_initialize_objfile, gdbpy_initialize_breakpoints,
gdbpy_initialize_finishbreakpoints,
gdbpy_initialize_lazy_string, gdbpy_initialize_parameters,
gdbpy_initialize_thread, gdbpy_initialize_inferior,
gdbpy_initialize_eventregistry, gdbpy_initialize_event,
gdbpy_initialize_py_events, gdbpy_initialize_stop_event,
gdbpy_initialize_signal_event,
gdbpy_initialize_breakpoint_event,
gdbpy_initialize_continue_event,
gdbpy_initialize_exited_event, gdbpy_initialize_thread_event,
gdbpy_initialize_new_objfile_event, gdbpy_initialize_arch):
Update. Use CPYCHECKER_NEGATIVE_RESULT_SETS_EXCEPTION.
* python/python.c (gdb_python_initialized): New global.
(gdbpy_initialize_events): Return 'int'. Check errors.
(_initialize_python): Check errors. Set
gdb_python_initialized.
2013-05-20 20:28:52 +00:00
|
|
|
|
return -1;
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
2011-01-06 00:57:05 +00:00
|
|
|
|
/* Note: These would probably be best exposed as class attributes of
|
|
|
|
|
|
Frame, but I don't know how to do it except by messing with the
|
|
|
|
|
|
type's dictionary. That seems too messy. */
|
* python/py-arch.c (gdbpy_initialize_arch): Return 'int'.
Check errors.
* python/py-auto-load.c (gdbpy_initialize_auto_load): Return 'int'.
* python/py-block.c (gdbpy_initialize_blocks): Return 'int'.
Check errors.
* python/py-breakpoint.c (gdbpy_initialize_breakpoints): Return 'int'.
Check errors.
* python/py-cmd.c (gdbpy_initialize_commands): Return 'int'.
Check errors.
* python/py-event.c (gdbpy_initialize_event): Return 'int'.
Check errors.
* python/py-event.h (GDBPY_NEW_EVENT_TYPE): Change generated
init function to return 'int'.
* python/py-evtregistry.c (gdbpy_initialize_eventregistry):
Return 'int'. Check errors.
* python/py-evts.c (gdbpy_initialize_py_events): Return 'int'.
Check errors.
* python/py-finishbreakpoint.c (gdbpy_initialize_finishbreakpoints):
Return 'int'. Check errors.
* python/py-frame.c (gdbpy_initialize_frames): Return 'int'.
Check errors.
* python/py-function.c (gdbpy_initialize_functions): Return 'int'.
Check errors.
* python/py-gdb-readline.c (gdbpy_initialize_gdb_readline):
Check errors.
* python/py-inferior.c (gdbpy_initialize_inferior): Return 'int'.
Check errors.
* python/py-infthread.c (gdbpy_initialize_thread): Return 'int'.
Check errors.
* python/py-lazy-string.c (gdbpy_initialize_lazy_string): Return 'int'.
Check errors.
* python/py-objfile.c (gdbpy_initialize_objfile): Return 'int'.
Check errors.
* python/py-param.c (gdbpy_initialize_parameters): Return 'int'.
Check errors.
* python/py-progspace.c (gdbpy_initialize_pspace): Return 'int'.
Check errors.
* python/py-symbol.c (gdbpy_initialize_symbols): Return 'int'.
Check errors.
* python/py-symtab.c (gdbpy_initialize_symtabs): Return 'int'.
Check errors.
* python/py-type.c (gdbpy_initialize_types): Return 'int'.
Check errors.
* python/py-value.c (gdbpy_initialize_values): Return 'int'.
Check errors.
* python/python-internal.h (gdbpy_initialize_auto_load,
gdbpy_initialize_values, gdbpy_initialize_frames,
gdbpy_initialize_symtabs, gdbpy_initialize_commands,
gdbpy_initialize_symbols, gdbpy_initialize_symtabs,
gdbpy_initialize_blocks, gdbpy_initialize_types,
gdbpy_initialize_functions, gdbpy_initialize_pspace,
gdbpy_initialize_objfile, gdbpy_initialize_breakpoints,
gdbpy_initialize_finishbreakpoints,
gdbpy_initialize_lazy_string, gdbpy_initialize_parameters,
gdbpy_initialize_thread, gdbpy_initialize_inferior,
gdbpy_initialize_eventregistry, gdbpy_initialize_event,
gdbpy_initialize_py_events, gdbpy_initialize_stop_event,
gdbpy_initialize_signal_event,
gdbpy_initialize_breakpoint_event,
gdbpy_initialize_continue_event,
gdbpy_initialize_exited_event, gdbpy_initialize_thread_event,
gdbpy_initialize_new_objfile_event, gdbpy_initialize_arch):
Update. Use CPYCHECKER_NEGATIVE_RESULT_SETS_EXCEPTION.
* python/python.c (gdb_python_initialized): New global.
(gdbpy_initialize_events): Return 'int'. Check errors.
(_initialize_python): Check errors. Set
gdb_python_initialized.
2013-05-20 20:28:52 +00:00
|
|
|
|
if (PyModule_AddIntConstant (gdb_module, "NORMAL_FRAME", NORMAL_FRAME) < 0
|
|
|
|
|
|
|| PyModule_AddIntConstant (gdb_module, "DUMMY_FRAME", DUMMY_FRAME) < 0
|
|
|
|
|
|
|| PyModule_AddIntConstant (gdb_module, "INLINE_FRAME", INLINE_FRAME) < 0
|
|
|
|
|
|
|| PyModule_AddIntConstant (gdb_module, "TAILCALL_FRAME",
|
|
|
|
|
|
TAILCALL_FRAME) < 0
|
|
|
|
|
|
|| PyModule_AddIntConstant (gdb_module, "SIGTRAMP_FRAME",
|
|
|
|
|
|
SIGTRAMP_FRAME) < 0
|
|
|
|
|
|
|| PyModule_AddIntConstant (gdb_module, "ARCH_FRAME", ARCH_FRAME) < 0
|
|
|
|
|
|
|| PyModule_AddIntConstant (gdb_module, "SENTINEL_FRAME",
|
|
|
|
|
|
SENTINEL_FRAME) < 0)
|
|
|
|
|
|
return -1;
|
2011-10-27 11:04:27 +00:00
|
|
|
|
|
|
|
|
|
|
#define SET(name, description) \
|
* python/py-arch.c (gdbpy_initialize_arch): Return 'int'.
Check errors.
* python/py-auto-load.c (gdbpy_initialize_auto_load): Return 'int'.
* python/py-block.c (gdbpy_initialize_blocks): Return 'int'.
Check errors.
* python/py-breakpoint.c (gdbpy_initialize_breakpoints): Return 'int'.
Check errors.
* python/py-cmd.c (gdbpy_initialize_commands): Return 'int'.
Check errors.
* python/py-event.c (gdbpy_initialize_event): Return 'int'.
Check errors.
* python/py-event.h (GDBPY_NEW_EVENT_TYPE): Change generated
init function to return 'int'.
* python/py-evtregistry.c (gdbpy_initialize_eventregistry):
Return 'int'. Check errors.
* python/py-evts.c (gdbpy_initialize_py_events): Return 'int'.
Check errors.
* python/py-finishbreakpoint.c (gdbpy_initialize_finishbreakpoints):
Return 'int'. Check errors.
* python/py-frame.c (gdbpy_initialize_frames): Return 'int'.
Check errors.
* python/py-function.c (gdbpy_initialize_functions): Return 'int'.
Check errors.
* python/py-gdb-readline.c (gdbpy_initialize_gdb_readline):
Check errors.
* python/py-inferior.c (gdbpy_initialize_inferior): Return 'int'.
Check errors.
* python/py-infthread.c (gdbpy_initialize_thread): Return 'int'.
Check errors.
* python/py-lazy-string.c (gdbpy_initialize_lazy_string): Return 'int'.
Check errors.
* python/py-objfile.c (gdbpy_initialize_objfile): Return 'int'.
Check errors.
* python/py-param.c (gdbpy_initialize_parameters): Return 'int'.
Check errors.
* python/py-progspace.c (gdbpy_initialize_pspace): Return 'int'.
Check errors.
* python/py-symbol.c (gdbpy_initialize_symbols): Return 'int'.
Check errors.
* python/py-symtab.c (gdbpy_initialize_symtabs): Return 'int'.
Check errors.
* python/py-type.c (gdbpy_initialize_types): Return 'int'.
Check errors.
* python/py-value.c (gdbpy_initialize_values): Return 'int'.
Check errors.
* python/python-internal.h (gdbpy_initialize_auto_load,
gdbpy_initialize_values, gdbpy_initialize_frames,
gdbpy_initialize_symtabs, gdbpy_initialize_commands,
gdbpy_initialize_symbols, gdbpy_initialize_symtabs,
gdbpy_initialize_blocks, gdbpy_initialize_types,
gdbpy_initialize_functions, gdbpy_initialize_pspace,
gdbpy_initialize_objfile, gdbpy_initialize_breakpoints,
gdbpy_initialize_finishbreakpoints,
gdbpy_initialize_lazy_string, gdbpy_initialize_parameters,
gdbpy_initialize_thread, gdbpy_initialize_inferior,
gdbpy_initialize_eventregistry, gdbpy_initialize_event,
gdbpy_initialize_py_events, gdbpy_initialize_stop_event,
gdbpy_initialize_signal_event,
gdbpy_initialize_breakpoint_event,
gdbpy_initialize_continue_event,
gdbpy_initialize_exited_event, gdbpy_initialize_thread_event,
gdbpy_initialize_new_objfile_event, gdbpy_initialize_arch):
Update. Use CPYCHECKER_NEGATIVE_RESULT_SETS_EXCEPTION.
* python/python.c (gdb_python_initialized): New global.
(gdbpy_initialize_events): Return 'int'. Check errors.
(_initialize_python): Check errors. Set
gdb_python_initialized.
2013-05-20 20:28:52 +00:00
|
|
|
|
if (PyModule_AddIntConstant (gdb_module, "FRAME_"#name, name) < 0) \
|
|
|
|
|
|
return -1;
|
2011-10-27 11:04:27 +00:00
|
|
|
|
#include "unwind_stop_reasons.def"
|
|
|
|
|
|
#undef SET
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
2024-09-11 10:35:20 -06:00
|
|
|
|
return 0;
|
2009-03-30 19:54:33 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
gdb/python: add mechanism to manage Python initialization functions
Currently, when we add a new python sub-system to GDB,
e.g. py-inferior.c, we end up having to create a new function like
gdbpy_initialize_inferior, which then has to be called from the
function do_start_initialization in python.c.
In some cases (py-micmd.c and py-tui.c), we have two functions
gdbpy_initialize_*, and gdbpy_finalize_*, with the second being called
from finalize_python which is also in python.c.
This commit proposes a mechanism to manage these initialization and
finalization calls, this means that adding a new Python subsystem will
no longer require changes to python.c or python-internal.h, instead,
the initialization and finalization functions will be registered
directly from the sub-system file, e.g. py-inferior.c, or py-micmd.c.
The initialization and finalization functions are managed through a
new class gdbpy_initialize_file in python-internal.h. This class
contains a single global vector of all the initialization and
finalization functions.
In each Python sub-system we create a new gdbpy_initialize_file
object, the object constructor takes care of registering the two
callback functions.
Now from python.c we can call static functions on the
gdbpy_initialize_file class which take care of walking the callback
list and invoking each callback in turn.
To slightly simplify the Python sub-system files I added a new macro
GDBPY_INITIALIZE_FILE, which hides the need to create an object. We
can now just do this:
GDBPY_INITIALIZE_FILE (gdbpy_initialize_registers);
One possible problem with this change is that there is now no
guaranteed ordering of how the various sub-systems are initialized (or
finalized). To try and avoid dependencies creeping in I have added a
use of the environment variable GDB_REVERSE_INIT_FUNCTIONS, this is
the same environment variable used in the generated init.c file.
Just like with init.c, when this environment variable is set we
reverse the list of Python initialization (and finalization)
functions. As there is already a test that starts GDB with the
environment variable set then this should offer some level of
protection against dependencies creeping in - though for full
protection I guess we'd need to run all gdb.python/*.exp tests with
the variable set.
I have tested this patch with the environment variable set, and saw no
regressions, so I think we are fine right now.
One other change of note was for gdbpy_initialize_gdb_readline, this
function previously returned void. In order to make this function
have the correct signature I've updated its return type to int, and we
now return 0 to indicate success.
All of the other initialize (and finalize) functions have been made
static within their respective sub-system files.
There should be no user visible changes after this commit.
2022-09-16 16:08:17 +01:00
|
|
|
|
GDBPY_INITIALIZE_FILE (gdbpy_initialize_frames);
|
|
|
|
|
|
|
2009-03-30 19:54:33 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
static PyMethodDef frame_object_methods[] = {
|
|
|
|
|
|
{ "is_valid", frapy_is_valid, METH_NOARGS,
|
|
|
|
|
|
"is_valid () -> Boolean.\n\
|
|
|
|
|
|
Return true if this frame is valid, false if not." },
|
|
|
|
|
|
{ "name", frapy_name, METH_NOARGS,
|
|
|
|
|
|
"name () -> String.\n\
|
|
|
|
|
|
Return the function name of the frame, or None if it can't be determined." },
|
|
|
|
|
|
{ "type", frapy_type, METH_NOARGS,
|
|
|
|
|
|
"type () -> Integer.\n\
|
|
|
|
|
|
Return the type of the frame." },
|
2013-01-23 19:59:13 +00:00
|
|
|
|
{ "architecture", frapy_arch, METH_NOARGS,
|
|
|
|
|
|
"architecture () -> gdb.Architecture.\n\
|
|
|
|
|
|
Return the architecture of the frame." },
|
2009-03-30 19:54:33 +00:00
|
|
|
|
{ "unwind_stop_reason", frapy_unwind_stop_reason, METH_NOARGS,
|
|
|
|
|
|
"unwind_stop_reason () -> Integer.\n\
|
|
|
|
|
|
Return the reason why it's not possible to find frames older than this." },
|
|
|
|
|
|
{ "pc", frapy_pc, METH_NOARGS,
|
|
|
|
|
|
"pc () -> Long.\n\
|
|
|
|
|
|
Return the frame's resume address." },
|
2023-03-30 10:40:41 +01:00
|
|
|
|
{ "read_register", (PyCFunction) frapy_read_register,
|
|
|
|
|
|
METH_VARARGS | METH_KEYWORDS,
|
2014-09-03 16:34:47 -07:00
|
|
|
|
"read_register (register_name) -> gdb.Value\n\
|
|
|
|
|
|
Return the value of the register in the frame." },
|
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
Tom Tromey <tromey@redhat.com>
Thiago Jung Bauermann <bauerman@br.ibm.com>
* python/python.c (_initialize_python): Call
gdbpy_initialize_symtabs, gdbpy_initialize_symbols and
gdbpy_initialize_blocks.
* python/python-internal.h: Declare struct symbol, block and
symtab_and_line. Declare block_object_type and
symbol_object_type
(gdbpy_lookup_symbol gdbpy_block_for_pc)
(symtab_and_line_to_sal_object, symtab_to_symtab_object)
(symbol_to_symbol_object, block_to_block_object)
(gdbpy_initialize_symtabs,gdbpy_initialize_symbols)
(gdbpy_initialize_blocks ): Declare.
* python/py-frame.c (frapy_block, frapy_function, frapy_find_sal)
(frapy_select): Add methods.
(frapy_read_var): Add symbol branch.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-symbol, py-symtab,
py-block.
(SUBDIR_PYTHON_SRCS): Likewise.
(py-symbol.o): New rule.
(py-symtab.o): Likewise.
(py-block.o): Likewise.
* python/py-symbol.c: New file.
* python/py-symtab.c: Likewise.
* python/py-block.c: Likewise.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* Makefile.in: Add py-block and py-symbol.
* gdb.python/py-symbol.exp: New File.
* gdb.python/py-symtab.exp: New File.
* gdb.python/py-block.exp: New File.
* gdb.python/py-symbol.c: New File.
* gdb.python/py-block.c: New File.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Frames In Python): Add block, find_sal, function
and select method descriptions.
(Python API): Add Blocks In Python, Symbols in Python and Symbol
Tables in Python to menu.
(Blocks In Python): New node.
(Symbols In Python): New node.
(Symbol Tables in Python): New node.
2010-02-24 21:18:28 +00:00
|
|
|
|
{ "block", frapy_block, METH_NOARGS,
|
|
|
|
|
|
"block () -> gdb.Block.\n\
|
|
|
|
|
|
Return the frame's code block." },
|
|
|
|
|
|
{ "function", frapy_function, METH_NOARGS,
|
|
|
|
|
|
"function () -> gdb.Symbol.\n\
|
|
|
|
|
|
Returns the symbol for the function corresponding to this frame." },
|
2009-03-30 19:54:33 +00:00
|
|
|
|
{ "older", frapy_older, METH_NOARGS,
|
|
|
|
|
|
"older () -> gdb.Frame.\n\
|
|
|
|
|
|
Return the frame that called this frame." },
|
|
|
|
|
|
{ "newer", frapy_newer, METH_NOARGS,
|
|
|
|
|
|
"newer () -> gdb.Frame.\n\
|
|
|
|
|
|
Return the frame called by this frame." },
|
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
Tom Tromey <tromey@redhat.com>
Thiago Jung Bauermann <bauerman@br.ibm.com>
* python/python.c (_initialize_python): Call
gdbpy_initialize_symtabs, gdbpy_initialize_symbols and
gdbpy_initialize_blocks.
* python/python-internal.h: Declare struct symbol, block and
symtab_and_line. Declare block_object_type and
symbol_object_type
(gdbpy_lookup_symbol gdbpy_block_for_pc)
(symtab_and_line_to_sal_object, symtab_to_symtab_object)
(symbol_to_symbol_object, block_to_block_object)
(gdbpy_initialize_symtabs,gdbpy_initialize_symbols)
(gdbpy_initialize_blocks ): Declare.
* python/py-frame.c (frapy_block, frapy_function, frapy_find_sal)
(frapy_select): Add methods.
(frapy_read_var): Add symbol branch.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-symbol, py-symtab,
py-block.
(SUBDIR_PYTHON_SRCS): Likewise.
(py-symbol.o): New rule.
(py-symtab.o): Likewise.
(py-block.o): Likewise.
* python/py-symbol.c: New file.
* python/py-symtab.c: Likewise.
* python/py-block.c: Likewise.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* Makefile.in: Add py-block and py-symbol.
* gdb.python/py-symbol.exp: New File.
* gdb.python/py-symtab.exp: New File.
* gdb.python/py-block.exp: New File.
* gdb.python/py-symbol.c: New File.
* gdb.python/py-block.c: New File.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Frames In Python): Add block, find_sal, function
and select method descriptions.
(Python API): Add Blocks In Python, Symbols in Python and Symbol
Tables in Python to menu.
(Blocks In Python): New node.
(Symbols In Python): New node.
(Symbol Tables in Python): New node.
2010-02-24 21:18:28 +00:00
|
|
|
|
{ "find_sal", frapy_find_sal, METH_NOARGS,
|
|
|
|
|
|
"find_sal () -> gdb.Symtab_and_line.\n\
|
|
|
|
|
|
Return the frame's symtab and line." },
|
gdb/python: allow Frame.read_var to accept named arguments
This commit allows Frame.read_var to accept named arguments, and also
improves (I think) some of the error messages emitted when values of
the wrong type are passed to this function.
The read_var method takes two arguments, one a variable, which is
either a gdb.Symbol or a string, while the second, optional, argument
is always a gdb.Block.
I'm now using 'O!' as the format specifier for the second argument,
which allows the argument type to be checked early on. Currently, if
the second argument is of the wrong type then we get this error:
(gdb) python print(gdb.selected_frame().read_var("a1", "xxx"))
Traceback (most recent call last):
File "<string>", line 1, in <module>
RuntimeError: Second argument must be block.
Error while executing Python code.
(gdb)
After this commit, we now get an error like this:
(gdb) python print(gdb.selected_frame().read_var("a1", "xxx"))
Traceback (most recent call last):
File "<string>", line 1, in <module>
TypeError: argument 2 must be gdb.Block, not str
Error while executing Python code.
(gdb)
Changes are:
1. Exception type is TypeError not RuntimeError, this is unfortunate
as user code _could_ be relying on this, but I think the improvement
is worth the risk, user code relying on the exact exception type is
likely to be pretty rare,
2. New error message gives argument position and expected argument
type, as well as the type that was passed.
If the first argument, the variable, has the wrong type then the
previous exception was already a TypeError, however, I've updated the
text of the exception to more closely match the "standard" error
message we see above. If the first argument has the wrong type then
before this commit we saw this:
(gdb) python print(gdb.selected_frame().read_var(123))
Traceback (most recent call last):
File "<string>", line 1, in <module>
TypeError: Argument must be a symbol or string.
Error while executing Python code.
(gdb)
And after we see this:
(gdb) python print(gdb.selected_frame().read_var(123))
Traceback (most recent call last):
File "<string>", line 1, in <module>
TypeError: argument 1 must be gdb.Symbol or str, not int
Error while executing Python code.
(gdb)
For existing code that doesn't use named arguments and doesn't rely on
exceptions, there will be no changes after this commit.
Reviewed-By: Tom Tromey <tom@tromey.com>
2023-03-30 11:21:32 +01:00
|
|
|
|
{ "read_var", (PyCFunction) frapy_read_var, METH_VARARGS | METH_KEYWORDS,
|
2009-03-30 19:54:33 +00:00
|
|
|
|
"read_var (variable) -> gdb.Value.\n\
|
|
|
|
|
|
Return the value of the variable in this frame." },
|
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
Tom Tromey <tromey@redhat.com>
Thiago Jung Bauermann <bauerman@br.ibm.com>
* python/python.c (_initialize_python): Call
gdbpy_initialize_symtabs, gdbpy_initialize_symbols and
gdbpy_initialize_blocks.
* python/python-internal.h: Declare struct symbol, block and
symtab_and_line. Declare block_object_type and
symbol_object_type
(gdbpy_lookup_symbol gdbpy_block_for_pc)
(symtab_and_line_to_sal_object, symtab_to_symtab_object)
(symbol_to_symbol_object, block_to_block_object)
(gdbpy_initialize_symtabs,gdbpy_initialize_symbols)
(gdbpy_initialize_blocks ): Declare.
* python/py-frame.c (frapy_block, frapy_function, frapy_find_sal)
(frapy_select): Add methods.
(frapy_read_var): Add symbol branch.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-symbol, py-symtab,
py-block.
(SUBDIR_PYTHON_SRCS): Likewise.
(py-symbol.o): New rule.
(py-symtab.o): Likewise.
(py-block.o): Likewise.
* python/py-symbol.c: New file.
* python/py-symtab.c: Likewise.
* python/py-block.c: Likewise.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* Makefile.in: Add py-block and py-symbol.
* gdb.python/py-symbol.exp: New File.
* gdb.python/py-symtab.exp: New File.
* gdb.python/py-block.exp: New File.
* gdb.python/py-symbol.c: New File.
* gdb.python/py-block.c: New File.
2010-02-24 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Frames In Python): Add block, find_sal, function
and select method descriptions.
(Python API): Add Blocks In Python, Symbols in Python and Symbol
Tables in Python to menu.
(Blocks In Python): New node.
(Symbols In Python): New node.
(Symbol Tables in Python): New node.
2010-02-24 21:18:28 +00:00
|
|
|
|
{ "select", frapy_select, METH_NOARGS,
|
|
|
|
|
|
"Select this frame as the user's current frame." },
|
2021-05-26 22:01:59 +01:00
|
|
|
|
{ "level", frapy_level, METH_NOARGS,
|
|
|
|
|
|
"The stack level of this frame." },
|
2022-05-24 10:15:17 -06:00
|
|
|
|
{ "language", frapy_language, METH_NOARGS,
|
|
|
|
|
|
"The language of this frame." },
|
2023-10-24 08:05:06 -06:00
|
|
|
|
{ "static_link", frapy_static_link, METH_NOARGS,
|
|
|
|
|
|
"The static link of this frame, or None." },
|
2009-03-30 19:54:33 +00:00
|
|
|
|
{NULL} /* Sentinel */
|
|
|
|
|
|
};
|
|
|
|
|
|
|
2012-02-07 19:47:16 +00:00
|
|
|
|
PyTypeObject frame_object_type = {
|
2012-12-12 16:47:30 +00:00
|
|
|
|
PyVarObject_HEAD_INIT (NULL, 0)
|
2009-03-30 19:54:33 +00:00
|
|
|
|
"gdb.Frame", /* tp_name */
|
|
|
|
|
|
sizeof (frame_object), /* tp_basicsize */
|
|
|
|
|
|
0, /* tp_itemsize */
|
|
|
|
|
|
0, /* tp_dealloc */
|
|
|
|
|
|
0, /* tp_print */
|
|
|
|
|
|
0, /* tp_getattr */
|
|
|
|
|
|
0, /* tp_setattr */
|
|
|
|
|
|
0, /* tp_compare */
|
2024-01-04 10:57:40 +00:00
|
|
|
|
frapy_repr, /* tp_repr */
|
2009-03-30 19:54:33 +00:00
|
|
|
|
0, /* tp_as_number */
|
|
|
|
|
|
0, /* tp_as_sequence */
|
|
|
|
|
|
0, /* tp_as_mapping */
|
|
|
|
|
|
0, /* tp_hash */
|
|
|
|
|
|
0, /* tp_call */
|
|
|
|
|
|
frapy_str, /* tp_str */
|
|
|
|
|
|
0, /* tp_getattro */
|
|
|
|
|
|
0, /* tp_setattro */
|
|
|
|
|
|
0, /* tp_as_buffer */
|
|
|
|
|
|
Py_TPFLAGS_DEFAULT, /* tp_flags */
|
|
|
|
|
|
"GDB frame object", /* tp_doc */
|
|
|
|
|
|
0, /* tp_traverse */
|
|
|
|
|
|
0, /* tp_clear */
|
|
|
|
|
|
frapy_richcompare, /* tp_richcompare */
|
|
|
|
|
|
0, /* tp_weaklistoffset */
|
|
|
|
|
|
0, /* tp_iter */
|
|
|
|
|
|
0, /* tp_iternext */
|
|
|
|
|
|
frame_object_methods, /* tp_methods */
|
|
|
|
|
|
0, /* tp_members */
|
|
|
|
|
|
0, /* tp_getset */
|
|
|
|
|
|
0, /* tp_base */
|
|
|
|
|
|
0, /* tp_dict */
|
|
|
|
|
|
0, /* tp_descr_get */
|
|
|
|
|
|
0, /* tp_descr_set */
|
|
|
|
|
|
0, /* tp_dictoffset */
|
|
|
|
|
|
0, /* tp_init */
|
|
|
|
|
|
0, /* tp_alloc */
|
|
|
|
|
|
};
|