aboutsummaryrefslogtreecommitdiff
path: root/gdb/addrmap.h
blob: c530200e4a960aefaeed0bc56f1b9466faa0c29e (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
/* addrmap.h --- interface to address map data structure.

   Copyright (C) 2007-2022 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 3 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, see <http://www.gnu.org/licenses/>.  */

#ifndef ADDRMAP_H
#define ADDRMAP_H

#include "splay-tree.h"
#include "gdbsupport/function-view.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 type of a function used to iterate over the map.
   OBJ is NULL for unmapped regions.  */
typedef gdb::function_view<int (CORE_ADDR start_addr, void *obj)>
     addrmap_foreach_fn;

/* The base class for addrmaps.  */
struct addrmap : public allocate_on_obstack
{
  virtual ~addrmap () = default;

  virtual void set_empty (CORE_ADDR start, CORE_ADDR end_inclusive,
			  void *obj) = 0;
  virtual void *find (CORE_ADDR addr) const = 0;
  virtual struct addrmap *create_fixed (struct obstack *obstack) = 0;
  virtual void relocate (CORE_ADDR offset) = 0;
  virtual int foreach (addrmap_foreach_fn fn) = 0;
};

struct addrmap_mutable;

/* Fixed address maps.  */
struct addrmap_fixed : public addrmap
{
public:

  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 *find (CORE_ADDR addr) const override;
  struct addrmap *create_fixed (struct obstack *obstack) override;
  void relocate (CORE_ADDR offset) override;
  int foreach (addrmap_foreach_fn fn) override;

private:

  /* A transition: a point in an address map where the value changes.
     The map maps ADDR to VALUE, but if ADDR > 0, it maps ADDR-1 to
     something else.  */
  struct addrmap_transition
  {
    CORE_ADDR addr;
    void *value;
  };

  /* The number of transitions in TRANSITIONS.  */
  size_t num_transitions;

  /* An array of transitions, sorted by address.  For every point in
     the map where either ADDR == 0 or ADDR is mapped to one value and
     ADDR - 1 is mapped to something different, we have an entry here
     containing ADDR and VALUE.  (Note that this means we always have
     an entry for address 0).  */
  struct addrmap_transition *transitions;
};

/* Mutable address maps.  */

struct addrmap_mutable : public addrmap
{
public:

  explicit addrmap_mutable (struct obstack *obs);
  DISABLE_COPY_AND_ASSIGN (addrmap_mutable);

  void set_empty (CORE_ADDR start, CORE_ADDR end_inclusive,
		  void *obj) override;
  void *find (CORE_ADDR addr) const override;
  struct addrmap *create_fixed (struct obstack *obstack) override;
  void relocate (CORE_ADDR offset) override;
  int foreach (addrmap_foreach_fn fn) override;

private:

  /* The obstack to use for allocations for this map.  */
  struct obstack *obstack;

  /* A freelist for splay tree nodes, allocated on obstack, and
     chained together by their 'right' pointers.  */
  /* splay_tree_new_with_allocator uses the provided allocation
     function to allocate the main splay_tree structure itself, so our
     free list has to be initialized before we create the tree.  */
  splay_tree_node free_nodes = nullptr;

  /* A splay tree, with a node for each transition; there is a
     transition at address T if T-1 and T map to different objects.

     Any addresses below the first node map to NULL.  (Unlike
     fixed maps, we have no entry at (CORE_ADDR) 0; it doesn't 
     simplify enough.)

     The last region is assumed to end at CORE_ADDR_MAX.

     Since we can't know whether CORE_ADDR is larger or smaller than
     splay_tree_key (unsigned long) --- I think both are possible,
     given all combinations of 32- and 64-bit hosts and targets ---
     our keys are pointers to CORE_ADDR values.  Since the splay tree
     library doesn't pass any closure pointer to the key free
     function, we can't keep a freelist for keys.  Since mutable
     addrmaps are only used temporarily right now, we just leak keys
     from deleted nodes; they'll be freed when the obstack is freed.  */
  splay_tree tree;

  /* Various helper methods.  */
  splay_tree_key allocate_key (CORE_ADDR addr);
  void force_transition (CORE_ADDR addr);
  splay_tree_node splay_tree_lookup (CORE_ADDR addr) const;
  splay_tree_node splay_tree_predecessor (CORE_ADDR addr) const;
  splay_tree_node splay_tree_successor (CORE_ADDR addr);
  void splay_tree_remove (CORE_ADDR addr);
  void splay_tree_insert (CORE_ADDR key, void *value);

  static void *splay_obstack_alloc (int size, void *closure);
  static void splay_obstack_free (void *obj, void *closure);
};


/* 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 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 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 (const 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);

/* Call FN for every address in MAP, following an in-order traversal.
   If FN ever returns a non-zero value, the iteration ceases
   immediately, and the value is returned.  Otherwise, this function
   returns 0.  */
int addrmap_foreach (struct addrmap *map, addrmap_foreach_fn fn);

/* Dump the addrmap to OUTFILE.  If PAYLOAD is non-NULL, only dump any
   components that map to PAYLOAD.  (If PAYLOAD is NULL, the entire
   map is dumped.)  */
void addrmap_dump (struct addrmap *map, struct ui_file *outfile,
		   void *payload);

#endif /* ADDRMAP_H */