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.
This commit is contained in:
parent
c420411fe8
commit
801e3a5b56
13 changed files with 947 additions and 32 deletions
96
gdb/addrmap.h
Normal file
96
gdb/addrmap.h
Normal file
|
@ -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 */
|
Loading…
Add table
Add a link
Reference in a new issue