This particular change in commit
965deba1208 ("gdb: use
gdb::unordered_{set,map} at a few places") causes some regressions,
for instance when running gdb.base/catch-fork-kill.exp:
(gdb) PASS: gdb.base/catch-fork-kill.exp: fork-kind=fork: exit-kind=exit: fork: continue to child fork
continue^M
Continuing.^M
[Attaching after Thread 0x7ffff7e74740 (LWP 490949) fork to child process 490952]^M
[New inferior 2 (process 490952)]^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".^M
=================================================================^M
^[[1m^[[31m==490919==ERROR: AddressSanitizer: heap-use-after-free on address 0x7c9bac051d88 at pc 0x55f46adc7583 bp 0x7ffc862a1e90 sp 0x7ffc862a1e80
Function x86_linux_nat_target::low_new_fork calls function
x86_debug_reg_state twice in a row. The first one returns a reference
to an x86_debug_reg_state object in the map. The second causes an
insertion to be made, moving the first object, rendering the first
reference invalid.
Revert the change and add a comment indicating that the location of
x86_debug_reg_state objects is important.
Change-Id: I85789d7657bec658a01908117efa25611e660878
/* Hash table storing per-process data. We don't bind this to a
per-inferior registry because of targets like x86 GNU/Linux that
need to keep track of processes that aren't bound to any inferior
- (e.g., fork children, checkpoints). */
+ (e.g., fork children, checkpoints).
-static gdb::unordered_map<pid_t,
+ Use std::unordered_map rather than gdb::unordered_map, because the
+ location of entries must not change across two x86_debug_reg_state(ptid_t)
+ calls. */
+
+static std::unordered_map<pid_t,
struct x86_debug_reg_state> x86_debug_process_state;
/* See x86-nat.h. */