aboutsummaryrefslogtreecommitdiff
path: root/gdb/addrmap.h
diff options
context:
space:
mode:
authorJim Blandy <jimb@codesourcery.com>2007-12-04 23:43:57 +0000
committerJim Blandy <jimb@codesourcery.com>2007-12-04 23:43:57 +0000
commit801e3a5b5681c44b2fec1b392dddec386870647c (patch)
treefc5540169fef73f5721542765234f47023c7763d /gdb/addrmap.h
parentc420411fe81ad583b2154fd9338fd0076761d99d (diff)
downloadfsf-binutils-gdb-801e3a5b5681c44b2fec1b392dddec386870647c.zip
fsf-binutils-gdb-801e3a5b5681c44b2fec1b392dddec386870647c.tar.gz
fsf-binutils-gdb-801e3a5b5681c44b2fec1b392dddec386870647c.tar.bz2
Support lexical blocks and function bodies that occupy
non-contiguous address ranges. * addrmap.c, addrmap.h: New files. * block.h (struct addrmap): New forward declaration. (struct blockvector): New member, 'map'. (BLOCKVECTOR_MAP): New accessor macro. * block.c: #include "addrmap.h" (blockvector_for_pc_sect): If the blockvector we've found has an address map, use it instead of searching the blocks. * buildsym.c: #include "addrmap.h" (pending_addrmap_obstack, pending_addrmap_interesting): New static variables. (really_free_pendings): If we have a pending addrmap, free it too. (record_block_range): New function. (make_blockvector): If we have an interesting pending addrmap, record it in the new blockvector. (start_symtab, buildsym_init): Assert that there is no pending addrmap now; we should have cleaned up any addrmaps we'd built previously. (end_symtab): If there is a pending addrmap left over that didn't get included in the blockvector, free it. * buildsym.h (struct addrmap): New forward declaration. (record_block_range): New prototype. * objfiles.c: #include "addrmap.h". (objfile_relocate): Relocate the blockvector's address map, if present. * dwarf2read.c (dwarf2_record_block_ranges): New function. (read_func_scope, read_lexical_block_scope): Call it. * Makefile.in (SFILES): Add addrmap.c. (addrmap_h): New header dependency variable. (COMMON_OBS): Add addrmap.o. (addrmap.o): New rule.l (block.o, objfiles.o, buildsym.o): Depend on $(addrmap_h). * block.c (blockvector_for_pc, blockvector_for_pc_sect): Return a pointer to the block, not its index in the blockvector. (block_for_pc_sect): Use the returned block, instead of looking it up ourselves. * block.h (blockvector_for_pc, blockvector_for_pc_sect): Update declarations. * breakpoint.c (resolve_sal_pc): Use returned block, instead of looking it up ourselves. * stack.c (print_frame_label_vars): Disable function, which depends on the block's index. * buildsym.c (finish_block): Return the block we've built. * buildsym.h (finish_block): Update prototype. * defs.h (CORE_ADDR_MAX): New constant.
Diffstat (limited to 'gdb/addrmap.h')
-rw-r--r--gdb/addrmap.h96
1 files changed, 96 insertions, 0 deletions
diff --git a/gdb/addrmap.h b/gdb/addrmap.h
new file mode 100644
index 0000000..8fa1873
--- /dev/null
+++ b/gdb/addrmap.h
@@ -0,0 +1,96 @@
+/* addrmap.h --- interface to address map data structure.
+
+ Copyright (C) 2007 Free Software Foundation, Inc.
+
+ This file is part of GDB.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software
+ Foundation, Inc., 51 Franklin Street, Fifth Floor,
+ Boston, MA 02110-1301, USA. */
+
+#ifndef ADDRMAP_H
+#define ADDRMAP_H
+
+/* An address map is essentially a table mapping CORE_ADDRs onto GDB
+ data structures, like blocks, symtabs, partial symtabs, and so on.
+ An address map uses memory proportional to the number of
+ transitions in the map, where a CORE_ADDR N is mapped to one
+ object, and N+1 is mapped to a different object.
+
+ Address maps come in two flavors: fixed, and mutable. Mutable
+ address maps consume more memory, but can be changed and extended.
+ A fixed address map, once constructed (from a mutable address map),
+ can't be edited. Both kinds of map are allocated in obstacks. */
+
+/* The opaque type representing address maps. */
+struct addrmap;
+
+/* Create a mutable address map which maps every address to NULL.
+ Allocate entries in OBSTACK. */
+struct addrmap *addrmap_create_mutable (struct obstack *obstack);
+
+/* 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 menas 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 addrmap_set_empty (struct addrmap *map,
+ CORE_ADDR start, CORE_ADDR end_inclusive,
+ void *obj);
+
+/* Return the object associated with ADDR in MAP. */
+void *addrmap_find (struct addrmap *map, CORE_ADDR addr);
+
+/* Create a fixed address map which is a copy of the mutable address
+ map ORIGINAL. Allocate entries in OBSTACK. */
+struct addrmap *addrmap_create_fixed (struct addrmap *original,
+ struct obstack *obstack);
+
+/* Relocate all the addresses in MAP by OFFSET. (This can be applied
+ to either mutable or immutable maps.) */
+void addrmap_relocate (struct addrmap *map, CORE_ADDR offset);
+
+#endif /* ADDRMAP_H */