[Bug symtab/30728] [gdb/symtab, cc-with-dwz] FAIL: gdb.cp/breakpoint-locs.exp: break N1::C1::baz

["vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=30728

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
I'm starting to understand somewhat why it's not 100% reproducible.  With this
patch:
...
diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index dd4fac52ca8..ed36b5e890b 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -16889,6 +16889,13 @@ cooked_index_functions::expand_symtabs_matching
        = lookup_name_without_params.split_name (lang);
       std::string last_name = gdb::to_string (name_vec.back ());

+      for (const cooked_index_entry *entry : table->find (last_name,
+                                                         completing))
+       {
+         QUIT;
+         fprintf (stderr, "Trying entry: %lx\n", (unsigned
long)entry->die_offset);
+       }
+
       for (const cooked_index_entry *entry : table->find (last_name,
                                                          completing))
        {
@@ -16953,6 +16960,7 @@ cooked_index_functions::expand_symtabs_matching
                continue;
            }

+         fprintf (stderr, "matched entry: %lx\n", (unsigned
long)entry->die_offset);
          if (!dw2_expand_symtabs_matching_one (entry->per_cu, per_objfile,
                                                file_matcher,
                                                expansion_notify))
...
I get:
...
$ gdb -q -batch ./breakpoint-locs -ex "break N1::C1::baz"
Trying entry: 14
Trying entry: 10e
Trying entry: 199
matched entry: 14
Trying entry: 2e
Trying entry: 2e
Trying entry: 2e
Breakpoint 1 at 0x4004db: file
/data/vries/gdb/src/gdb/testsuite/gdb.cp/breakpoint-locs.h, line 23.
...
or:
...
$ gdb -q -batch ./breakpoint-locs -ex "break N1::C1::baz"
Trying entry: 10e
Trying entry: 14
Trying entry: 199
matched entry: 10e
Trying entry: 2e
matched entry: 2e
Trying entry: 2e
Trying entry: 2e
Breakpoint 1 at 0x4004db: N1::C1::baz. (2 locations)
...

The root cause of the difference seems to be that the order of table->find is
not stable.

-- 
You are receiving this mail because:
You are on the CC list for the bug.