Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Fix crash when expanding partial symtabs with DW_TAG_imported_unit

PR gdb/27743 points out a gdb crash when expanding partial symtabs,
where one of the compilation units uses DW_TAG_imported_unit.

The bug is that partial_map_expand_apply expects only to be called for
the outermost psymtab.  However, filename searching doesn't (and
probably shouldn't) guarantee this.  The fix is to walk upward to find
the outermost CU.

A new test case is included.  It is mostly copied from other test
cases, which really sped up the effort.

This bug does not occur on trunk.  There,
psym_map_symtabs_matching_filename is gone, replaced by
psymbol_functions::expand_symtabs_matching.  When this find a match,
it calls psymtab_to_symtab, which does this same upward walk.

Tested on x86-64 Fedora 32.

I propose checking in this patch on the gdb-10 branch, and just the
new test case on trunk.

gdb/ChangeLog
2021-04-23  Tom Tromey  <tromey@adacore.com>

PR gdb/27743:
* psymtab.c (partial_map_expand_apply): Expand outermost psymtab.

gdb/testsuite/ChangeLog
2021-04-23  Tom Tromey  <tromey@adacore.com>

PR gdb/27743:
* gdb.dwarf2/imported-unit-bp.exp: New file.
* gdb.dwarf2/imported-unit-bp-main.c: New file.
* gdb.dwarf2/imported-unit-bp-alt.c: New file.

Automatic date update in version.in

Bump GDB version number to 10.2.90.DATE-git.

gdb/ChangeLog:

* version.in: Set GDB version number to 10.2.90.DATE-git.

gdb/testsuite/ChangeLog:

* gdb.base/default.exp: Change $_gdb_minor to 3.

Document the GDB 10.2 release in gdb/ChangeLog

gdb/ChangeLog:

GDB 10.2 released.

Set GDB version number to 10.2.

gdb/ChangeLog:

* version.in: Set GDB version number to 10.2.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

gdb/testsuite: add Python support check in gdb.python/flexible-array-member.exp

We don't want to execute this test if Python support is not compiled in
GDB, add the necessary check.

gdb/testsuite/ChangeLog:

* gdb.python/flexible-array-member.exp: Add check for Python
support.

Change-Id: I853b937d2a193a0bb216566bef1a35354264b1c5

gdb: fix getting range of flexible array member in Python

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

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in