This rewrites registry.h, removing all the macros and replacing it
with relatively ordinary template classes. The result is less code
than the previous setup. It replaces large macros with a relatively
straightforward C++ class, and now manages its own cleanup.
The existing type-safe "key" class is replaced with the equivalent
template class. This approach ended up requiring relatively few
changes to the users of the registry code in gdb -- code using the key
system just required a small change to the key's declaration.
All existing users of the old C-like API are now converted to use the
type-safe API. This mostly involved changing explicit deletion
functions to be an operator() in a deleter class.
The old "save/free" two-phase process is removed, and replaced with a
single "free" phase. No existing code used both phases.
The old "free" callbacks took a parameter for the enclosing container
object. However, this wasn't truly needed and is removed here as
well.
When an objfile is destroyed, types that are still in use and
allocated on that objfile are copied. A temporary hash map is created
during this process, and it is allocated on the destroyed objfile's
obstack -- which normally is fine, as that is going to be destroyed
shortly anyway.
However, this approach requires that the objfile be passed to registry
destruction, and this won't be possible in the rewritten registry.
This patch changes the copied type hash table to simply use the heap
instead. It also removes the 'objfile' parameter from
copy_type_recursive, to make this all more clear.
This patch also fixes an apparent bug in copy_type_recursive.
Previously it was copying the dynamic property list to the dying
objfile's obstack:
- = copy_dynamic_prop_list (&objfile->objfile_obstack,
However I think this is incorrect -- that obstack is about to be
destroyed.
I noticed a few spots that were explicitly creating new references to
Py_True or Py_False. It's simpler here to use PyBool_FromLong, so
this patch changes all the places I found.
New in this version:
- Rebase on master, fix a few more issues that appeared.
python-internal.h contains a number of macros that helped make the code
work with both Python 2 and 3. Remove them and adjust the code to use
the Python 3 functions.
Change-Id: I99a3d80067fb2d65de4f69f6473ba6ffd16efb2d
New in this version:
- Add a PY_MAJOR_VERSION check in configure.ac / AC_TRY_LIBPYTHON. If
the user passes --with-python=python2, this will cause a configure
failure saying that GDB only supports Python 3.
Support for Python 2 is a maintenance burden for any patches touching
Python support. Among others, the differences between Python 2 and 3
string and integer types are subtle. It requires a lot of effort and
thinking to get something that behaves correctly on both. And that's if
the author and reviewer of the patch even remember to test with Python
2.
See this thread for an example:
https://sourceware.org/pipermail/gdb-patches/2021-December/184260.html
So, remove Python 2 support. Update the documentation to state that GDB
can be built against Python 3 (as opposed to Python 2 or 3).
Update all the spots that use:
- sys.version_info
- IS_PY3K
- PY_MAJOR_VERSION
- gdb_py_is_py3k
... to only keep the Python 3 portions and drop the use of some
now-removed compatibility macros.
I did not update the configure script more than just removing the
explicit references to Python 2. We could maybe do more there, like
check the Python version and reject it if that version is not
supported. Otherwise (with this patch), things will only fail at
compile time, so it won't really be clear to the user that they are
trying to use an unsupported Python version. But I'm a bit lost in the
configure code that checks for Python, so I kept that for later.
Change-Id: I75b0f79c148afbe3c07ac664cfa9cade052c0c62
Add a new read-only property, Type.is_signed, which is True for signed
types, and False otherwise.
This property should only be read on types for which Type.is_scalar is
true, attempting to read this property for non-scalar types will raise
a ValueError.
I chose 'is_signed' rather than 'is_unsigned' in order to match the
existing Architecture.integer_type method, which takes a 'signed'
parameter. As far as I could find, that was the only existing
signed/unsigned selector in the Python API, so it seemed reasonable to
stay consistent.
Make use of a range based for loop to iterate over a static global
array, removing the need to have a null entry at the end of the
array.
There should be no user visible changes after this commit.
Add a getter and a setter for a symbol's type. Remove the corresponding
macro and adjust all callers.
Change-Id: Ie1a137744c5bfe1df4d4f9ae5541c5299577c8de
Currently, gdb's Python layer captures the current architecture and
language when "entering" Python code. This has some undesirable
effects, and so this series changes how this is handled.
First, there is code like this:
gdbpy_enter enter_py (python_gdbarch, python_language);
This is incorrect, because both of these are NULL when not otherwise
assigned. This can cause crashes in some cases -- I've added one to
the test suite. (Note that this crasher is just an example, other
ones along the same lines are possible.)
Second, when the language is captured in this way, it means that
Python code cannot affect the current language for its own purposes.
It's reasonable to want to write code like this:
gdb.execute('set language mumble')
... stuff using the current language
gdb.execute('set language previous-value')
However, this won't actually work, because the language is captured on
entry. I've added a test to show this as well.
This patch changes gdb to try to avoid capturing the current values.
The Python concept of the current gdbarch is only set in those few
cases where a non-default value is computed or needed; and the
language is not captured at all -- instead, in the cases where it's
required, the current language is temporarily changed.
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
Remove the `TYPE_FIELD_NAME` and `FIELD_NAME` macros, changing all the
call sites to use field::name directly.
Change-Id: I6900ae4e1ffab1396e24fb3298e94bf123826ca6
I noticed that pointer_type is declared in language.h and defined in
language.c. However, it really has to do with types, so it should
have been in gdbtypes.h all along.
This patch changes it to be a method on struct type. And, I went
through uses of TYPE_IS_REFERENCE and updated many spots to use the
new method as well. (I didn't update ones that were in arch-specific
code, as I couldn't readily test that.)
Python 2 has a bit flag Py_TPFLAGS_HAVE_ITER which can be passed as
part of the tp_flags field when defining a new object type. This flag
is not defined in Python 3 and so we define it to 0 in
python-internal.h (when IS_PY3K is defined).
The meaning of this flag is that the object has the fields tp_iter and
tp_iternext. Note the use of "has" here, the flag says nothing about
the values in those fields, just that the type object has the fields.
In early versions of Python 2 these fields were no part of the
PyTypeObject struct, they were added in version 2.2 (see
https://docs.python.org/release/2.3/api/type-structs.html). And so,
there could be a some code compiled out there which has a PyTypeObject
structure within it that doesn't even have the tp_iter and tp_iternext
fields, attempting to access these fields would be undefined
behaviour.
And so Python added the Py_TPFLAGS_HAVE_ITER flag. If the flag is
present then Python is free to access the tp_iter and tp_iternext
fields.
If we consider GDB then we always assume that the tp_iter and
tp_iternext fields are part of PyTypeObject. If someone was crazy
enough to try and compile GDB against Python 2.1 then we'd get lots of
build errors saying that we were passing too many fields when
initializing PyTypeObject structures. And so, I claim, we can be sure
that GDB will always be compiled with a version of Python that has the
tp_iter and tp_iternext fields in PyTypeObject.
Next we can look at the Py_TPFLAGS_DEFAULT flag. In Python 2, each
time additional fields are added to PyTypeObject a new Py_TPFLAGS_*
flag would be defined to indicate whether those flags are present or
not. And, those new flags would be added to Py_TPFLAGS_DEFAULT. And
so, in the latest version of Python 2 the Py_TPFLAGS_DEFAULT flag
includes Py_TPFLAGS_HAVE_ITER (see
https://docs.python.org/2.7/c-api/typeobj.html).
In GDB we pass Py_TPFLAGS_DEFAULT as part of the tp_flags for all
objects we define.
And so, in this commit, I propose to remove all uses of
Py_TPFLAGS_HAVE_ITER from GDB, it's simply not needed.
There should be no user visible changes after this commit.
GNAT emits encoded type names, but these aren't usually of interest to
users. The Ada language code in gdb hides this oddity -- but the
Python layer does not. This patch changes the Python code to use the
decoded Ada type name, when appropriate.
I looked at decoding Ada type names during construction, as that would
be cleaner. However, the Ada support in gdb relies on the encodings
at various points, so this isn't really doable right now.
2021-06-25 Tom Tromey <tromey@adacore.com>
* python/py-type.c (typy_get_name): Decode an Ada type name.
gdb/testsuite/ChangeLog
2021-06-25 Tom Tromey <tromey@adacore.com>
* gdb.ada/py_range.exp: Add type name test cases.
Delay Python initialisation until gdbpy_finish_initialization.
This is mostly about splitting the existing gdbpy_initialize_*
functions in two, all the calls to register_objfile_data_with_cleanup,
gdbarch_data_register_post_init, etc are moved into new _initialize_*
functions, but everything else is left in the gdbpy_initialize_*
functions.
Then the call to do_start_initialization (in python/python.c) is moved
from the _initialize_python function into gdbpy_finish_initialization.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* python/py-arch.c (_initialize_py_arch): New function.
(gdbpy_initialize_arch): Move code to _initialize_py_arch.
* python/py-block.c (_initialize_py_block): New function.
(gdbpy_initialize_blocks): Move code to _initialize_py_block.
* python/py-inferior.c (_initialize_py_inferior): New function.
(gdbpy_initialize_inferior): Move code to _initialize_py_inferior.
* python/py-objfile.c (_initialize_py_objfile): New function.
(gdbpy_initialize_objfile): Move code to _initialize_py_objfile.
* python/py-progspace.c (_initialize_py_progspace): New function.
(gdbpy_initialize_pspace): Move code to _initialize_py_progspace.
* python/py-registers.c (_initialize_py_registers): New function.
(gdbpy_initialize_registers): Move code to
_initialize_py_registers.
* python/py-symbol.c (_initialize_py_symbol): New function.
(gdbpy_initialize_symbols): Move code to _initialize_py_symbol.
* python/py-symtab.c (_initialize_py_symtab): New function.
(gdbpy_initialize_symtabs): Move code to _initialize_py_symtab.
* python/py-type.c (_initialize_py_type): New function.
(gdbpy_initialize_types): Move code to _initialize_py_type.
* python/py-unwind.c (_initialize_py_unwind): New function.
(gdbpy_initialize_unwind): Move code to _initialize_py_unwind.
* python/python.c (_initialize_python): Move call to
do_start_initialization to gdbpy_finish_initialization.
(gdbpy_finish_initialization): Add call to
do_start_initialization.
As reported in bug 27757, we get an internal error when doing:
$ cat test.c
struct foo {
int len;
int items[];
};
struct foo *p;
int main() {
return 0;
}
$ gcc test.c -g -O0 -o test
$ ./gdb -q -nx --data-directory=data-directory ./test -ex 'python gdb.parse_and_eval("p").type.target()["items"].type.range()'
Reading symbols from ./test...
/home/simark/src/binutils-gdb/gdb/gdbtypes.h:435: internal-error: LONGEST dynamic_prop::const_val() const: Assertion `m_kind == PROP_CONST' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
This is because the Python code (typy_range) blindly reads the high
bound of the type of `items` as a constant value. Since it is a
flexible array member, it has no high bound, the property is undefined.
Since commit 8c2e4e0689 ("gdb: add accessors to struct dynamic_prop"),
the getters check that you are not getting a property value of the wrong
kind, so this causes a failed assertion.
Fix it by checking if the property is indeed a constant value before
accessing it as such. Otherwise, use 0. This restores the previous GDB
behavior: because the structure was zero-initialized, this is what was
returned before. But now this behavior is explicit and not accidental.
Add a test, gdb.python/flexible-array-member.exp, that is derived from
gdb.base/flexible-array-member.exp. It tests the same things, but
through the Python API. It also specifically tests getting the range
from the various kinds of flexible array member types (AFAIK it wasn't
possible to do the equivalent through the CLI).
gdb/ChangeLog:
PR gdb/27757
* python/py-type.c (typy_range): Check that bounds are constant
before accessing them as such.
* guile/scm-type.c (gdbscm_type_range): Likewise.
gdb/testsuite/ChangeLog:
PR gdb/27757
* gdb.python/flexible-array-member.c: New test.
* gdb.python/flexible-array-member.exp: New test.
* gdb.guile/scm-type.exp (test_range): Add test for flexible
array member.
* gdb.guile/scm-type.c (struct flex_member): New.
(main): Use it.
Change-Id: Ibef92ee5fd871ecb7c791db2a788f203dff2b841
I think this makes the names of the methods clearer, especially for the
arch. The type::arch method (which gets the arch owner, or NULL if the
type is not arch owned) is easily confused with the get_type_arch method
(which returns an arch no matter what). The name "arch_owner" will make
it intuitive that the method returns NULL if the type is not arch-owned.
Also, this frees the type::arch name, so we will be able to morph the
get_type_arch function into the type::arch method.
gdb/ChangeLog:
* gdbtypes.h (struct type) <arch>: Rename to...
<arch_owner>: ... this, update all users.
<objfile>: Rename to...
<objfile_owner>: ... this, update all users.
Change-Id: Ie7c28684c7b565adec05a7619c418c69429bd8c0
Change all users to use the type::objfile method instead.
gdb/ChangeLog:
* gdbtypes.h (TYPE_OBJFILE): Remove, change all users to use the
type::objfile method instead.
Change-Id: I6b3f580913fb1fb0cf986b176dba8db68e1fabf9
This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...
gdb/ChangeLog
Update copyright year range in copyright header of all GDB files.
Considering this example:
struct C
{
int func() { return 1; }
} c;
int main()
{
return c.func();
}
Accessing the fields of C::func, when requesting the function by its
type, works:
(gdb) py print(gdb.parse_and_eval('C::func').type.fields()[0].type)
C * const
But when trying to do the same via a class instance, it fails:
(gdb) py print(gdb.parse_and_eval('c')['func'].type.fields()[0].type)
Traceback (most recent call last):
File "<string>", line 1, in <module>
TypeError: Type is not a structure, union, enum, or function type.
Error while executing Python code.
The difference is that in the former the function type is TYPE_CODE_FUNC:
(gdb) py print(gdb.parse_and_eval('C::func').type.code == gdb.TYPE_CODE_FUNC)
True
And in the latter the function type is TYPE_CODE_METHOD:
(gdb) py print(gdb.parse_and_eval('c')['func'].type.code == gdb.TYPE_CODE_METHOD)
True
So this adds the functionality for TYPE_CODE_METHOD as well.
gdb/ChangeLog:
2020-12-18 Hannes Domani <ssbssa@yahoo.de>
* python/py-type.c (typy_get_composite): Add TYPE_CODE_METHOD.
gdb/testsuite/ChangeLog:
2020-12-18 Hannes Domani <ssbssa@yahoo.de>
* gdb.python/py-type.exp: Add tests for TYPE_CODE_METHOD.
Avoid the use of PyInt_FromLong, preferring gdb_py_object_from_longest
instead. I found found another spot that was incorrectly handling
errors (see gdbpy_create_ptid_object) while writing this patch; it is
fixed here.
gdb/ChangeLog
2020-09-15 Tom Tromey <tromey@adacore.com>
* python/python-internal.h (PyInt_FromLong): Remove define.
* python/py-value.c (convert_value_from_python): Use
gdb_py_object_from_longest.
* python/py-type.c (typy_get_code): Use
gdb_py_object_from_longest.
* python/py-symtab.c (salpy_get_line): Use
gdb_py_object_from_longest.
* python/py-symbol.c (sympy_get_addr_class, sympy_line): Use
gdb_py_object_from_longest.
* python/py-record.c (recpy_gap_reason_code): Use
gdb_py_object_from_longest.
* python/py-record-btrace.c (recpy_bt_insn_size)
(recpy_bt_func_level, btpy_list_count): Use
gdb_py_object_from_longest.
* python/py-infthread.c (gdbpy_create_ptid_object): Use
gdb_py_object_from_longest. Fix error handling.
* python/py-framefilter.c (bootstrap_python_frame_filters): Use
gdb_py_object_from_longest.
* python/py-frame.c (frapy_type, frapy_unwind_stop_reason): Use
gdb_py_object_from_longest.
* python/py-breakpoint.c (bppy_get_type, bppy_get_number)
(bppy_get_thread, bppy_get_task, bppy_get_hit_count)
(bppy_get_ignore_count): Use gdb_py_object_from_longest.
This changes gdb to avoid PyLong_FromLong, preferring to
gdb_py_object_from_longest instead.
gdb/ChangeLog
2020-09-15 Tom Tromey <tromey@adacore.com>
* python/python.c (gdbpy_parameter_value): Use
gdb_py_object_from_longest.
* python/py-type.c (convert_field, typy_range): Use
gdb_py_object_from_longest.
* python/py-tui.c (gdbpy_tui_width, gdbpy_tui_height): Use
gdb_py_object_from_longest.
* python/py-lazy-string.c (stpy_get_length): Use
gdb_py_object_from_longest.
* python/py-infthread.c (thpy_get_num, thpy_get_global_num): Use
gdb_py_object_from_longest.
* python/py-infevents.c (create_memory_changed_event_object): Use
gdb_py_object_from_longest.
* python/py-inferior.c (infpy_get_num): Use
gdb_py_object_from_longest.
(infpy_get_pid): Likewise.
Change the Python layer to avoid gdb_py_long_from_longest, and remove
the defines.
gdb/ChangeLog
2020-09-15 Tom Tromey <tromey@adacore.com>
* python/python-internal.h (gdb_py_long_from_longest): Remove
defines.
* python/py-value.c (valpy_long): Use gdb_py_object_from_longest.
* python/py-type.c (convert_field, typy_get_sizeof): Use
gdb_py_object_from_longest.
* python/py-record-btrace.c (btpy_list_index): Use
gdb_py_object_from_longest.
Getting the bounds of an array (or string) type is a common operation,
and is currently done through its index type:
my_array_type->index_type ()->bounds ()
I think it would make sense to let the `type::bounds` methods work for
arrays and strings, as a shorthand for this. It's natural that when
asking for the bounds of an array, we get the bounds of the range type
used as its index type. In a way, it's equivalent as the now-removed
TYPE_ARRAY_{LOWER,UPPER}_BOUND_IS_UNDEFINED and
TYPE_ARRAY_{LOWER,UPPER}_BOUND_VALUE, except it returns the
`range_bounds` object. The caller is then responsible for getting the
property it needs in it.
I updated all the spots I could find that could take advantage of this.
Note that this also makes `type::bit_stride` work on array types, since
`type::bit_stride` uses `type::bounds`. `my_array_type->bit_stride ()`
now returns the bit stride of the array's index type. So some spots
are also changed to take advantage of this.
gdb/ChangeLog:
* gdbtypes.h (struct type) <bounds>: Handle array and string
types.
* ada-lang.c (assign_aggregate): Use type::bounds on
array/string type.
* c-typeprint.c (c_type_print_varspec_suffix): Likewise.
* c-varobj.c (c_number_of_children): Likewise.
(c_describe_child): Likewise.
* eval.c (evaluate_subexp_for_sizeof): Likewise.
* f-typeprint.c (f_type_print_varspec_suffix): Likewise.
(f_type_print_base): Likewise.
* f-valprint.c (f77_array_offset_tbl): Likewise.
(f77_get_upperbound): Likewise.
(f77_print_array_1): Likewise.
* guile/scm-type.c (gdbscm_type_range): Likewise.
* m2-typeprint.c (m2_array): Likewise.
(m2_is_long_set_of_type): Likewise.
* m2-valprint.c (get_long_set_bounds): Likewise.
* p-typeprint.c (pascal_type_print_varspec_prefix): Likewise.
* python/py-type.c (typy_range): Likewise.
* rust-lang.c (rust_internal_print_type): Likewise.
* type-stack.c (type_stack::follow_types): Likewise.
* valarith.c (value_subscripted_rvalue): Likewise.
* valops.c (value_cast): Likewise.
Change-Id: I5c0c08930bffe42fd69cb4bfcece28944dd88d1f
Remove the macros, use the getters of `struct dynamic_prop` instead.
gdb/ChangeLog:
* gdbtypes.h (TYPE_LOW_BOUND, TYPE_HIGH_BOUND): Remove. Update
all callers to use type::range_bounds followed by
dynamic_prop::{low,high}.
Change-Id: I31beeed65d94d81ac4f999244a8b859e2ee961d1
Remove the `TYPE_FIELD_TYPE` macro, changing all the call sites to use
`type::field` and `field::type` directly.
gdb/ChangeLog:
* gdbtypes.h (TYPE_FIELD_TYPE): Remove. Change all call sites
to use type::field and field::type instead.
Change-Id: Ifda6226a25c811cfd334a756a9fbc5c0afdddff3
Remove `TYPE_INDEX_TYPE` macro, changing all the call sites to use
`type::index_type` directly.
gdb/ChangeLog:
* gdbtypes.h (TYPE_INDEX_TYPE): Remove. Change all call sites
to use type::index_type instead.
Change-Id: I56715df0bdec89463cda6bd341dac0e01b2faf84
Replace all uses of it by type::field.
Note that since type::field returns a reference to the field, some spots
are used to assign the whole field structure. See ctfread.c, function
attach_fields_to_type, for example. This is the same as was happening
with the macro, so I don't think it's a problem, but if anybody sees a
really nicer way to do this, now could be a good time to implement it.
gdb/ChangeLog:
* gdbtypes.h (TYPE_FIELD): Remove. Replace all uses with
type::field.
Remove `TYPE_NFIELDS`, changing all the call sites to use
`type::num_fields` directly. This is quite a big diff, but this was
mostly done using sed and coccinelle. A few call sites were done by
hand.
gdb/ChangeLog:
* gdbtypes.h (TYPE_NFIELDS): Remove. Change all cal sites to use
type::num_fields instead.
Change-Id: Ib73be4c36f9e770e0f729bac3b5257d7cb2f9591
Remove `TYPE_NAME`, changing all the call sites to use `type::name`
directly. This is quite a big diff, but this was mostly done using sed
and coccinelle. A few call sites were done by hand.
gdb/ChangeLog:
* gdbtypes.h (TYPE_NAME): Remove. Change all cal sites to use
type::name instead.
Remove TYPE_CODE, changing all the call sites to use type::code
directly. This is quite a big diff, but this was mostly done using sed
and coccinelle. A few call sites were done by hand.
gdb/ChangeLog:
* gdbtypes.h (TYPE_CODE): Remove. Change all call sites to use
type::code instead.
This changes the gdb Python API to add support for dynamic types. In
particular, this adds an attribute to gdb.Type, and updates some
attributes to reflect dynamic sizes and field offsets.
There's still no way to get the dynamic type from one of its concrete
instances. This could perhaps be added if needed.
gdb/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
PR python/23662:
* python/py-type.c (convert_field): Handle
FIELD_LOC_KIND_DWARF_BLOCK.
(typy_get_sizeof): Handle TYPE_HAS_DYNAMIC_LENGTH.
(typy_get_dynamic): Nw function.
(type_object_getset): Add "dynamic".
* NEWS: Add entry.
gdb/doc/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
PR python/23662:
* python.texi (Types In Python): Document new features.
gdb/testsuite/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
PR python/23662:
* gdb.ada/variant.exp: Add Python checks.
* gdb.rust/simple.exp: Add dynamic type checks.
valgrind reports leaks in many python tests, such as:
==17162== VALGRIND_GDB_ERROR_BEGIN
==17162== 8,208 (5,472 direct, 2,736 indirect) bytes in 57 blocks are definitely lost in loss record 7,551 of 7,679
==17162== at 0x4835753: malloc (vg_replace_malloc.c:307)
==17162== by 0x6EAFD1: _PyObject_New (object.c:279)
==17162== by 0x4720E6: blpy_iter(_object*) (py-block.c:92)
==17162== by 0x698772: PyObject_GetIter (abstract.c:2577)
==17162== by 0x2343BE: _PyEval_EvalFrameDefault (ceval.c:3159)
==17162== by 0x22E9E2: function_code_fastcall (call.c:283)
==17162== by 0x2340A8: _PyObject_Vectorcall (abstract.h:127)
==17162== by 0x2340A8: call_function (ceval.c:4987)
==17162== by 0x2340A8: _PyEval_EvalFrameDefault (ceval.c:3486)
==17162== by 0x22E9E2: function_code_fastcall (call.c:283)
==17162== by 0x82172B: _PyObject_Vectorcall (abstract.h:127)
==17162== by 0x82172B: method_vectorcall (classobject.c:67)
==17162== by 0x6AF474: _PyObject_Vectorcall (abstract.h:127)
==17162== by 0x6AF474: _PyObject_CallNoArg (abstract.h:153)
==17162== by 0x6AF474: _PyObject_CallFunctionVa (call.c:914)
==17162== by 0x6B0673: callmethod (call.c:1010)
==17162== by 0x6B0673: _PyObject_CallMethod_SizeT (call.c:1103)
==17162== by 0x477DFE: gdb_PyObject_CallMethod<> (python-internal.h:182)
==17162== by 0x477DFE: get_py_iter_from_func(_object*, char const*) (py-framefilter.c:272)
==17162== by 0x4791B4: py_print_args (py-framefilter.c:706)
==17162== by 0x4791B4: py_print_frame(_object*, enum_flags<frame_filter_flag>, ext_lang_frame_args, ui_out*, int, htab*) (py-framefilter.c:960)
==17162== by 0x47A130: gdbpy_apply_frame_filter(extension_language_defn const*, frame_info*, enum_flags<frame_filter_flag>, ext_lang_frame_args, ui_out*, int, int) (py-framefilter.c:1236)
==17162== by 0x369C39: apply_ext_lang_frame_filter(frame_info*, enum_flags<frame_filter_flag>, ext_lang_frame_args, ui_out*, int, int) (extension.c:563)
==17162== by 0x4EC9C9: backtrace_command_1 (stack.c:2031)
==17162== by 0x4EC9C9: backtrace_command(char const*, int) (stack.c:2183)
...
Most of the leaks in python tests are due to the fact that many
PyObject xxxxx_dealloc functions are missing the line to free self
or obj such as:
Py_TYPE (self)->tp_free (self);
or
Py_TYPE (obj)->tp_free (obj);
With this patch, the number of python tests leaking decreases from 52 to 12.
gdb/ChangeLog
2019-11-18 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* python/py-block.c (blpy_dealloc): Call tp_free.
(blpy_block_syms_dealloc): Likewise.
* python/py-finishbreakpoint.c (bpfinishpy_dealloc): Likewise.
* python/py-inferior.c (infpy_dealloc): Likewise.
* python/py-lazy-string.c (stpy_dealloc): Likewise.
* python/py-linetable.c (ltpy_iterator_dealloc): Likewise.
* python/py-symbol.c (sympy_dealloc): Likewise.
* python/py-symtab.c (stpy_dealloc): Likewise.
* python/py-type.c (typy_iterator_dealloc): Likewise.
dwarf2read.c will create stub types for Ada "Taft Amendment" types.
These stub types can currently be exposed to Python code, where they
show up as TYPE_CODE_VOID types (but that, mysteriously, can sometimes
be used in other ways).
While it's possible to work with such types by using strip_typedefs,
this seemed unpleasant to me. This patch takes another approach
instead, which is to try not to expose stub types to Python users.
gdb/ChangeLog
2019-09-26 Tom Tromey <tromey@adacore.com>
* python/py-type.c (type_to_type_object): Call check_typedef
for stub types.
gdb/testsuite/ChangeLog
2019-09-26 Tom Tromey <tromey@adacore.com>
* gdb.ada/py_taft.exp: New file.
* gdb.ada/py_taft/main.adb: New file.
* gdb.ada/py_taft/pkg.adb: New file.
* gdb.ada/py_taft/pkg.ads: New file.
