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

This turns allocate_optimized_out_value into a static "constructor" of
value.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.

A user noticed that TYPE_CODE_FIXED_POINT was not exported by the gdb
Python layer.  This patch fixes the bug, and prevents future
occurences of this type of bug.

Remove the macro, replace all uses with calls to type::length.

Change-Id: Ib9bdc954576860b21190886534c99103d6a47afb

Remove the macro, replace all uses by calls to type::target_type.

Change-Id: Ie51d3e1e22f94130176d6abd723255282bb6d1ed

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.

Add a new read-only property which is True for scalar types,
otherwise, it's False.

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.

This removes the LA_PRINT_TYPE macro, in favor of using ordinary
method calls.

Add a getter and a setter for a symbol's type.  Remove the corresponding
macro and adjust all callers.

Change-Id: Ie1a137744c5bfe1df4d4f9ae5541c5299577c8de

Change-Id: I83211d5a47efc0564386e5b5ea4a29c00b1fd46a

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 TYPE_FIELD_ENUMVAL, replace with type::field +
field::loc_enumval.

Change-Id: I2ada73e4635aad3363ce2eb22c1dc52698ee2072

Remove TYPE_FIELD_BITPOS, replace its uses with type::field +
field::loc_bitpos.

Change-Id: Iccd8d5a77e5352843a837babaa6bd284162e0320

Remove TYPE_FIELD_LOC_KIND, replace its uses with type::field +
field::loc_kind.

Change-Id: Ib124a26365df82ac1d23df7962d954192913bd90

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 8c2e4e06 ("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.

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.

This changes create_copied_types_hash to return an htab_up, then
modifies the callers to avoid explicit use of htab_delete.

gdb/ChangeLog
2020-09-17  Tom Tromey  <tom@tromey.com>

	* value.c (preserve_values): Update.
	* python/py-type.c (save_objfile_types): Update.
	* guile/scm-type.c (save_objfile_types): Update.
	* gdbtypes.h (create_copied_types_hash): Return htab_up.
	* gdbtypes.c (create_copied_types_hash): Return htab_up.
	* compile/compile-object-run.c (compile_object_run): Update.

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.

gdb/ChangeLog:

	* gdbtypes.h (TYPE_STUB): Remove, replace all
	uses with type::is_stub.

Change-Id: Iec25b50449a0d10a38f815209e478c343e98632c

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