{
virtual ~addrmap () = default;
- /* In the mutable address map MAP, associate the addresses from START
- to END_INCLUSIVE that are currently associated with NULL with OBJ
- instead. Addresses mapped to an object other than NULL are left
- unchanged.
-
- As the name suggests, END_INCLUSIVE is also mapped to OBJ. This
- convention is unusual, but it allows callers to accurately specify
- ranges that abut the top of the address space, and ranges that
- cover the entire address space.
-
- This operation seems a bit complicated for a primitive: if it's
- needed, why not just have a simpler primitive operation that sets a
- range to a value, wiping out whatever was there before, and then
- let the caller construct more complicated operations from that,
- along with some others for traversal?
-
- It turns out this is the mutation operation we want to use all the
- time, at least for now. Our immediate use for address maps is to
- represent lexical blocks whose address ranges are not contiguous.
- We walk the tree of lexical blocks present in the debug info, and
- only create 'struct block' objects after we've traversed all a
- block's children. If a lexical block declares no local variables
- (and isn't the lexical block for a function's body), we omit it
- from GDB's data structures entirely.
-
- However, this means that we don't decide to create a block (and
- thus record it in the address map) until after we've traversed its
- children. If we do decide to create the block, we do so at a time
- when all its children have already been recorded in the map. So
- this operation --- change only those addresses left unset --- is
- actually the operation we want to use every time.
-
- It seems simpler to let the code which operates on the
- representation directly deal with the hair of implementing these
- semantics than to provide an interface which allows it to be
- implemented efficiently, but doesn't reveal too much of the
- representation. */
- virtual void set_empty (CORE_ADDR start, CORE_ADDR end_inclusive,
- void *obj) = 0;
-
/* Return the object associated with ADDR in MAP. */
const void *find (CORE_ADDR addr) const
{ return this->do_find (addr); }
addrmap_fixed (struct obstack *obstack, addrmap_mutable *mut);
DISABLE_COPY_AND_ASSIGN (addrmap_fixed);
- void set_empty (CORE_ADDR start, CORE_ADDR end_inclusive,
- void *obj) override;
void relocate (CORE_ADDR offset) override;
private:
~addrmap_mutable ();
DISABLE_COPY_AND_ASSIGN (addrmap_mutable);
+ /* In the mutable address map MAP, associate the addresses from START
+ to END_INCLUSIVE that are currently associated with NULL with OBJ
+ instead. Addresses mapped to an object other than NULL are left
+ unchanged.
+
+ As the name suggests, END_INCLUSIVE is also mapped to OBJ. This
+ convention is unusual, but it allows callers to accurately specify
+ ranges that abut the top of the address space, and ranges that
+ cover the entire address space.
+
+ This operation seems a bit complicated for a primitive: if it's
+ needed, why not just have a simpler primitive operation that sets a
+ range to a value, wiping out whatever was there before, and then
+ let the caller construct more complicated operations from that,
+ along with some others for traversal?
+
+ It turns out this is the mutation operation we want to use all the
+ time, at least for now. Our immediate use for address maps is to
+ represent lexical blocks whose address ranges are not contiguous.
+ We walk the tree of lexical blocks present in the debug info, and
+ only create 'struct block' objects after we've traversed all a
+ block's children. If a lexical block declares no local variables
+ (and isn't the lexical block for a function's body), we omit it
+ from GDB's data structures entirely.
+
+ However, this means that we don't decide to create a block (and
+ thus record it in the address map) until after we've traversed its
+ children. If we do decide to create the block, we do so at a time
+ when all its children have already been recorded in the map. So
+ this operation --- change only those addresses left unset --- is
+ actually the operation we want to use every time.
+
+ It seems simpler to let the code which operates on the
+ representation directly deal with the hair of implementing these
+ semantics than to provide an interface which allows it to be
+ implemented efficiently, but doesn't reveal too much of the
+ representation. */
void set_empty (CORE_ADDR start, CORE_ADDR end_inclusive,
- void *obj) override;
+ void *obj);
void relocate (CORE_ADDR offset) override;
private:
unrelocated_addr *,
unrelocated_addr *,
struct dwarf2_cu *,
- addrmap *,
+ addrmap_mutable *,
void *);
static void get_scope_pc_bounds (struct die_info *,
static int
dwarf2_ranges_read (unsigned offset, unrelocated_addr *low_return,
unrelocated_addr *high_return, struct dwarf2_cu *cu,
- addrmap *map, void *datum, dwarf_tag tag)
+ addrmap_mutable *map, void *datum, dwarf_tag tag)
{
dwarf2_per_objfile *per_objfile = cu->per_objfile;
int low_set = 0;
static pc_bounds_kind
dwarf_get_pc_bounds_ranges_or_highlow_pc (die_info *die, unrelocated_addr *low,
unrelocated_addr *high, dwarf2_cu *cu,
- addrmap *map, void *datum)
+ addrmap_mutable *map, void *datum)
{
gdb_assert (low != nullptr);
gdb_assert (high != nullptr);
static enum pc_bounds_kind
dwarf2_get_pc_bounds (struct die_info *die, unrelocated_addr *lowpc,
unrelocated_addr *highpc, struct dwarf2_cu *cu,
- addrmap *map, void *datum)
+ addrmap_mutable *map, void *datum)
{
dwarf2_per_objfile *per_objfile = cu->per_objfile;