aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/gdb.fortran/debug-expr.exp
AgeCommit message (Collapse)AuthorFilesLines
16 hoursUpdate copyright dates to include 2025Tom Tromey1-1/+1
This updates the copyright headers to include 2025. I did this by running gdb/copyright.py and then manually modifying a few files as noted by the script. Approved-By: Eli Zaretskii <eliz@gnu.org>
2024-01-12Update copyright year range in header of all files managed by GDBAndrew Burgess1-1/+1
This commit is the result of the following actions: - Running gdb/copyright.py to update all of the copyright headers to include 2024, - Manually updating a few files the copyright.py script told me to update, these files had copyright headers embedded within the file, - Regenerating gdbsupport/Makefile.in to refresh it's copyright date, - Using grep to find other files that still mentioned 2023. If these files were updated last year from 2022 to 2023 then I've updated them this year to 2024. I'm sure I've probably missed some dates. Feel free to fix them up as you spot them.
2023-01-13Rename to allow_fortran_testsTom Tromey1-1/+1
This changes skip_fortran_tests to invert the sense, and renames it to allow_fortran_tests.
2023-01-13Use require !gdb_debug_enabledTom Tromey1-4/+1
This changes some tests to use "require !gdb_debug_enabled".
2023-01-13Use require !skip_fortran_testsTom Tromey1-1/+1
This changes some tests to use "require !skip_fortran_tests".
2023-01-01Update copyright year range in header of all files managed by GDBJoel Brobecker1-1/+1
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.
2022-01-01Automatic Copyright Year update after running gdb/copyright.pyJoel Brobecker1-1/+1
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.
2021-09-30gdb/testsuite: make runto_main not pass no-message to runtoSimon Marchi1-1/+0
As follow-up to this discussion: https://sourceware.org/pipermail/gdb-patches/2020-August/171385.html ... make runto_main not pass no-message to runto. This means that if we fail to run to main, for some reason, we'll emit a FAIL. This is the behavior we want the majority of (if not all) the time. Without this, we rely on tests logging a failure if runto_main fails, otherwise. They do so in a very inconsisteny mannet, sometimes using "fail", "unsupported" or "untested". The messages also vary widly. This patch removes all these messages as well. Also, remove a few "fail" where we call runto (and not runto_main). by default (without an explicit no-message argument), runto prints a failure already. In two places, gdb.multi/multi-re-run.exp and gdb.python/py-pp-registration.exp, remove "message" passed to runto. This removes a few PASSes that we don't care about (but FAILs will still be printed if we fail to run to where we want to). This aligns their behavior with the rest of the testsuite. Change-Id: Ib763c98c5f4fb6898886b635210d7c34bd4b9023
2021-03-08Convert f-exp.y to use operationsTom Tromey1-4/+4
This converts the Fortran parser to generate operations rather than exp_elements. A couple of tests of expression debug dumping are updated to follow the new output. gdb/ChangeLog 2021-03-08 Tom Tromey <tom@tromey.com> * f-exp.y: Create operations. (f_language::parser): Update. gdb/testsuite/ChangeLog 2021-03-08 Tom Tromey <tom@tromey.com> * gdb.fortran/debug-expr.exp: Update tests.
2021-01-12gdb: fix debug dump of OP_BOOL expressionsAndrew Burgess1-0/+8
Consider this GDB session: (gdb) set language fortran (gdb) set debug expression 1 (gdb) p .TRUE. Dump of expression @ 0x4055d90, before conversion to prefix form: Language fortran, 3 elements, 16 bytes each. Index Opcode Hex Value String Value 0 OP_BOOL 79 O............... 1 BINOP_ADD 1 ................ 2 OP_BOOL 79 O............... Dump of expression @ 0x4055d90, after conversion to prefix form: Expression: `TRUE' Language fortran, 3 elements, 16 bytes each. 0 OP_BOOL Unknown format 1 BINOP_ADD 2 OP_BOOL Unknown format 3 OP_NULL Unknown format $1 = .TRUE. The final dump of the OP_BOOL is completely wrong. After this patch we now get: (gdb) set language fortran (gdb) set debug expression 1 (gdb) p .TRUE. Dump of expression @ 0x2d07470, before conversion to prefix form: Language fortran, 3 elements, 16 bytes each. Index Opcode Hex Value String Value 0 OP_BOOL 79 O............... 1 BINOP_ADD 1 ................ 2 OP_BOOL 79 O............... Dump of expression @ 0x2d07470, after conversion to prefix form: Expression: `TRUE' Language fortran, 3 elements, 16 bytes each. 0 OP_BOOL TRUE $1 = .TRUE. Much better. I added a test for this into the Fortran testsuite. gdb/ChangeLog: * expprint.c (dump_subexp_body_standard): Handle OP_BOOL. gdb/testsuite/ChangeLog: * gdb.fortran/debug-expr.exp: Add new tests.
2021-01-01Update copyright year range in all GDB filesJoel Brobecker1-1/+1
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.
2020-11-06gdb: fix debug expression dumping of function call expressionsAndrew Burgess1-0/+43
In commit: commit 6d81691950f8c4be4a49a85a672255c140e82468 CommitDate: Sat Sep 19 09:44:58 2020 +0100 gdb/fortran: Move Fortran expression handling into f-lang.c A bug was introduced that broke GDB's ability to perform debug dumps of expressions containing function calls. For example this would no longer work: (gdb) set debug expression 1 (gdb) print call_me (&val) Dump of expression @ 0x4eced60, before conversion to prefix form: Language c, 12 elements, 16 bytes each. Index Opcode Hex Value String Value 0 OP_VAR_VALUE 40 (............... 1 OP_M2_STRING 79862864 P............... 2 unknown opcode: 224 79862240 ................ 3 OP_VAR_VALUE 40 (............... 4 OP_VAR_VALUE 40 (............... 5 OP_RUST_ARRAY 79861600 `............... 6 UNOP_PREDECREMENT 79861312 @............... 7 OP_VAR_VALUE 40 (............... 8 UNOP_ADDR 61 =............... 9 OP_FUNCALL 46 ................ 10 BINOP_ADD 1 ................ 11 OP_FUNCALL 46 ................ Dump of expression @ 0x4eced60, after conversion to prefix form: Expression: `call_me (&main::val, VAL(Aborted (core dumped) The situation was even worse for Fortran function calls, or array indexes, which both make use of the same expression opcode. The problem was that in a couple of places the index into the expression array was handled incorrectly causing GDB to interpret elements incorrectly. These issues are fixed in this commit. There are already some tests to check GDB when 'set debug expression 1' is set, these can be found in gdb.*/debug-expr.exp. Unfortunately the cases above were not covered. In this commit I have cleaned up all of the debug-expr.exp files a little, there was a helper function that had clearly been copied into each file, this is now moved into lib/gdb.exp. I've added a gdb.fortran/debug-expr.exp test file, and extended gdb.base/debug-expr.exp to cover the function call case. gdb/ChangeLog: * expprint.c (print_subexp_funcall): Increment expression position after reading argument count. * f-lang.c (print_subexp_f): Skip over opcode before calling common function. (dump_subexp_body_f): Likewise. gdb/testsuite/ChangeLog: * gdb.base/debug-expr.c: Add extra function to allow for an additional test. * gdb.base/debug-expr.exp (test_debug_expr): Delete, replace calls to this proc with gdb_test_debug_expr. Add an extra test. * gdb.cp/debug-expr.exp (test_debug_expr): Delete, replace calls to this proc with gdb_test_debug_expr, give the tests names * gdb.dlang/debug-expr.exp (test_debug_expr): Delete, replace calls to this proc with gdb_test_debug_expr, give the tests names * gdb.fortran/debug-expr.exp: New file. * gdb.fortran/debug-expr.f90: New file. * lib/gdb.exp (gdb_test_debug_expr): New proc.
generated by cgit v1.1 at 2025-04-09 08:26:41 +0000