diff options
author | Jim Blandy <jimb@codesourcery.com> | 2007-12-04 23:43:57 +0000 |
---|---|---|
committer | Jim Blandy <jimb@codesourcery.com> | 2007-12-04 23:43:57 +0000 |
commit | 801e3a5b5681c44b2fec1b392dddec386870647c (patch) | |
tree | fc5540169fef73f5721542765234f47023c7763d /gdb/addrmap.h | |
parent | c420411fe81ad583b2154fd9338fd0076761d99d (diff) | |
download | gdb-801e3a5b5681c44b2fec1b392dddec386870647c.zip gdb-801e3a5b5681c44b2fec1b392dddec386870647c.tar.gz 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.h | 96 |
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 */ |