diff options
| author | Tom de Vries <tdevries@suse.de> | 2023-08-10 15:46:30 +0200 |
|---|---|---|
| committer | Tom de Vries <tdevries@suse.de> | 2023-08-10 15:46:30 +0200 |
| commit | 107ab8d45df84b442ce2d79c6dda3a9b3afc80d5 (patch) | |
| tree | 475e25e52f9146733b1d5368de5d4938eef2bd44 | |
| parent | 62a21046a98d081b5ac07afd0099dfd06465922c (diff) | |
| download | gdb-107ab8d45df84b442ce2d79c6dda3a9b3afc80d5.zip gdb-107ab8d45df84b442ce2d79c6dda3a9b3afc80d5.tar.gz gdb-107ab8d45df84b442ce2d79c6dda3a9b3afc80d5.tar.bz2 | |
[gdb/testsuite] Improve failure mode in gdb.dwarf2/enqueued-cu-base-addr.exp
I ran test-case gdb.dwarf2/enqueued-cu-base-addr.exp with target board
cc-with-debug-names, and ran into:
...
FAIL: gdb.dwarf2/enqueued-cu-base-addr.exp: ptype foo (GDB internal error)
FAIL: gdb.dwarf2/enqueued-cu-base-addr.exp: CU addr found
...
The first FAIL is a known issue, PR symtab/29572.
The following FAIL is a consequence of the first FAIL, so require for the
second test that the first test passes.
Tested on x86_64-linux, with target boards unix and cc-with-debug-names.
| -rw-r--r-- | gdb/testsuite/gdb.dwarf2/enqueued-cu-base-addr.exp | 10 |
1 files changed, 9 insertions, 1 deletions
diff --git a/gdb/testsuite/gdb.dwarf2/enqueued-cu-base-addr.exp b/gdb/testsuite/gdb.dwarf2/enqueued-cu-base-addr.exp index b60c020..9b2d1d8 100644 --- a/gdb/testsuite/gdb.dwarf2/enqueued-cu-base-addr.exp +++ b/gdb/testsuite/gdb.dwarf2/enqueued-cu-base-addr.exp @@ -76,7 +76,15 @@ if { [prepare_for_testing "failed to prepare" ${testfile} \ } # Expand cu1. This will enqueue cu2. -gdb_test "ptype foo" "type = int" +set cu1_expanded 0 +gdb_test_multiple "ptype foo" "" { + -re -wrap "type = int" { + set cu1_expanded 1 + pass $gdb_test_name + } +} + +require {expr $cu1_expanded == 1} # Now check that cu2 has an address range starting at main. set cu2_blockvector_re \ |