From 128070bb7426a7eeca0a0661a0eb7c81d8823f36 Mon Sep 17 00:00:00 2001 From: Pedro Alves Date: Mon, 27 Dec 2010 19:37:04 +0000 Subject: [PATCH] gdb/ * breakpoint.c (breakpoint_restore_shadows): When looking for the location with the lowest address that overlaps the memory range we want to restore shadows for, account for multiple locations at the same address. --- gdb/ChangeLog | 8 ++++++++ gdb/breakpoint.c | 17 +++++++++++++++++ 2 files changed, 25 insertions(+) diff --git a/gdb/ChangeLog b/gdb/ChangeLog index 51be0d254d3..fa158c00823 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,3 +1,11 @@ +2010-12-27 Pedro Alves + + gdb/ + * breakpoint.c (breakpoint_restore_shadows): When looking for the + location with the lowest address that overlaps the memory range we + want to restore shadows for, account for multiple locations at the + same address. + 2010-12-27 Jan Kratochvil Code cleanup - renaming. diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c index 5736fbc0b63..9835ad9bb94 100644 --- a/gdb/breakpoint.c +++ b/gdb/breakpoint.c @@ -1130,6 +1130,23 @@ breakpoint_restore_shadows (gdb_byte *buf, ULONGEST memaddr, LONGEST len) bc_r = bc; } + /* Due to the binary search above, we need to make sure we pick the + first location that's at BC_L's address. E.g., if there are + multiple locations at the same address, BC_L may end up pointing + at a duplicate location, and miss the "master"/"inserted" + location. Say, given locations L1, L2 and L3 at addresses A and + B: + + L1@A, L2@A, L3@B, ... + + BC_L could end up pointing at location L2, while the "master" + location could be L1. Since the `loc->inserted' flag is only set + on "master" locations, we'd forget to restore the shadow of L1 + and L2. */ + while (bc_l > 0 + && bp_location[bc_l]->address == bp_location[bc_l - 1]->address) + bc_l--; + /* Now do full processing of the found relevant range of elements. */ for (bc = bc_l; bc < bp_location_count; bc++) -- 2.30.2