aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-05-14Automatic date update in version.inGDB Administrator1-1/+1
2021-05-13Automatic date update in version.inGDB Administrator1-1/+1
2021-05-12Automatic date update in version.inGDB Administrator1-1/+1
2021-05-11Automatic date update in version.inGDB Administrator1-1/+1
2021-05-10Automatic date update in version.inGDB Administrator1-1/+1
2021-05-09Automatic date update in version.inGDB Administrator1-1/+1
2021-05-08Automatic date update in version.inGDB Administrator1-1/+1
2021-05-07Automatic date update in version.inGDB Administrator1-1/+1
2021-05-06Automatic date update in version.inGDB Administrator1-1/+1
2021-05-05Automatic date update in version.inGDB Administrator1-1/+1
2021-05-04Automatic date update in version.inGDB Administrator1-1/+1
2021-05-03Automatic date update in version.inGDB Administrator1-1/+1
2021-05-02Automatic date update in version.inGDB Administrator1-1/+1
2021-05-01Automatic date update in version.inGDB Administrator1-1/+1
2021-04-30Automatic date update in version.inGDB Administrator1-1/+1
2021-04-29Automatic date update in version.inGDB Administrator1-1/+1
2021-04-28Automatic date update in version.inGDB Administrator1-1/+1
2021-04-27Automatic date update in version.inGDB Administrator1-1/+1
2021-04-26Fix crash when expanding partial symtabs with DW_TAG_imported_unitTom Tromey6-3/+218
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.
2021-04-26Automatic date update in version.inGDB Administrator1-1/+1
2021-04-25Bump GDB version number to 10.2.90.DATE-git.Joel Brobecker4-2/+10
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.
2021-04-25Document the GDB 10.2 release in gdb/ChangeLogJoel Brobecker1-0/+4
gdb/ChangeLog: GDB 10.2 released.
2021-04-25Set GDB version number to 10.2.gdb-10.2-releaseJoel Brobecker2-1/+5
gdb/ChangeLog: * version.in: Set GDB version number to 10.2.
2021-04-25Automatic date update in version.inGDB Administrator1-1/+1
2021-04-24Automatic date update in version.inGDB Administrator1-1/+1
2021-04-23Automatic date update in version.inGDB Administrator1-1/+1
2021-04-22gdb/testsuite: add Python support check in gdb.python/flexible-array-member.expSimon Marchi2-0/+8
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
2021-04-22gdb: fix getting range of flexible array member in PythonSimon Marchi8-4/+227
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
2021-04-22Automatic date update in version.inGDB Administrator1-1/+1
2021-04-21Automatic date update in version.inGDB Administrator1-1/+1
2021-04-20Automatic date update in version.inGDB Administrator1-1/+1
2021-04-19Automatic date update in version.inGDB Administrator1-1/+1
2021-04-18Automatic date update in version.inGDB Administrator1-1/+1
2021-04-17Automatic date update in version.inGDB Administrator1-1/+1
2021-04-16Automatic date update in version.inGDB Administrator1-1/+1
2021-04-15Automatic date update in version.inGDB Administrator1-1/+1
2021-04-14Automatic date update in version.inGDB Administrator1-1/+1
2021-04-13Automatic date update in version.inGDB Administrator1-1/+1
2021-04-12Automatic date update in version.inGDB Administrator1-1/+1
2021-04-11Automatic date update in version.inGDB Administrator1-1/+1
2021-04-10Automatic date update in version.inGDB Administrator1-1/+1
2021-04-09Automatic date update in version.inGDB Administrator1-1/+1
2021-04-08Automatic date update in version.inGDB Administrator1-1/+1
2021-04-07Automatic date update in version.inGDB Administrator1-1/+1
2021-04-06Automatic date update in version.inGDB Administrator1-1/+1
2021-04-05Automatic date update in version.inGDB Administrator1-1/+1
2021-04-04Automatic date update in version.inGDB Administrator1-1/+1
2021-04-03Automatic date update in version.inGDB Administrator1-1/+1
2021-04-02Automatic date update in version.inGDB Administrator1-1/+1
2021-04-01Automatic date update in version.inGDB Administrator1-1/+1