PR symtab/12406:
[deliverable/binutils-gdb.git] / gdb / progspace.h
CommitLineData
6c95b8df
PA
1/* Program and address space management, for GDB, the GNU debugger.
2
0b302171 3 Copyright (C) 2009-2012 Free Software Foundation, Inc.
6c95b8df
PA
4
5 This file is part of GDB.
6
7 This program is free software; you can redistribute it and/or modify
8 it under the terms of the GNU General Public License as published by
9 the Free Software Foundation; either version 3 of the License, or
10 (at your option) any later version.
11
12 This program is distributed in the hope that it will be useful,
13 but WITHOUT ANY WARRANTY; without even the implied warranty of
14 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
15 GNU General Public License for more details.
16
17 You should have received a copy of the GNU General Public License
18 along with this program. If not, see <http://www.gnu.org/licenses/>. */
19
20
21#ifndef PROGSPACE_H
22#define PROGSPACE_H
23
24#include "target.h"
25#include "vec.h"
edcc5120 26#include "gdb_vecs.h"
6c95b8df
PA
27
28struct target_ops;
29struct bfd;
30struct objfile;
31struct inferior;
32struct exec;
33struct address_space;
34struct program_space_data;
35
edcc5120
TT
36typedef struct so_list *so_list_ptr;
37DEF_VEC_P (so_list_ptr);
38
6c95b8df
PA
39/* A program space represents a symbolic view of an address space.
40 Roughly speaking, it holds all the data associated with a
41 non-running-yet program (main executable, main symbols), and when
42 an inferior is running and is bound to it, includes the list of its
43 mapped in shared libraries.
44
45 In the traditional debugging scenario, there's a 1-1 correspondence
46 among program spaces, inferiors and address spaces, like so:
47
48 pspace1 (prog1) <--> inf1(pid1) <--> aspace1
49
50 In the case of debugging more than one traditional unix process or
51 program, we still have:
52
53 |-----------------+------------+---------|
54 | pspace1 (prog1) | inf1(pid1) | aspace1 |
55 |----------------------------------------|
56 | pspace2 (prog1) | no inf yet | aspace2 |
57 |-----------------+------------+---------|
58 | pspace3 (prog2) | inf2(pid2) | aspace3 |
59 |-----------------+------------+---------|
60
61 In the former example, if inf1 forks (and GDB stays attached to
62 both processes), the new child will have its own program and
63 address spaces. Like so:
64
65 |-----------------+------------+---------|
66 | pspace1 (prog1) | inf1(pid1) | aspace1 |
67 |-----------------+------------+---------|
68 | pspace2 (prog1) | inf2(pid2) | aspace2 |
69 |-----------------+------------+---------|
70
71 However, had inf1 from the latter case vforked instead, it would
72 share the program and address spaces with its parent, until it
73 execs or exits, like so:
74
75 |-----------------+------------+---------|
76 | pspace1 (prog1) | inf1(pid1) | aspace1 |
77 | | inf2(pid2) | |
78 |-----------------+------------+---------|
79
80 When the vfork child execs, it is finally given new program and
81 address spaces.
82
83 |-----------------+------------+---------|
84 | pspace1 (prog1) | inf1(pid1) | aspace1 |
85 |-----------------+------------+---------|
86 | pspace2 (prog1) | inf2(pid2) | aspace2 |
87 |-----------------+------------+---------|
88
89 There are targets where the OS (if any) doesn't provide memory
90 management or VM protection, where all inferiors share the same
91 address space --- e.g. uClinux. GDB models this by having all
92 inferiors share the same address space, but, giving each its own
93 program space, like so:
94
95 |-----------------+------------+---------|
96 | pspace1 (prog1) | inf1(pid1) | |
97 |-----------------+------------+ |
98 | pspace2 (prog1) | inf2(pid2) | aspace1 |
99 |-----------------+------------+ |
100 | pspace3 (prog2) | inf3(pid3) | |
101 |-----------------+------------+---------|
102
103 The address space sharing matters for run control and breakpoints
104 management. E.g., did we just hit a known breakpoint that we need
105 to step over? Is this breakpoint a duplicate of this other one, or
106 do I need to insert a trap?
107
108 Then, there are targets where all symbols look the same for all
109 inferiors, although each has its own address space, as e.g.,
110 Ericsson DICOS. In such case, the model is:
111
112 |---------+------------+---------|
113 | | inf1(pid1) | aspace1 |
114 | +------------+---------|
115 | pspace | inf2(pid2) | aspace2 |
116 | +------------+---------|
117 | | inf3(pid3) | aspace3 |
118 |---------+------------+---------|
119
120 Note however, that the DICOS debug API takes care of making GDB
121 believe that breakpoints are "global". That is, although each
122 process does have its own private copy of data symbols (just like a
123 bunch of forks), to the breakpoints module, all processes share a
124 single address space, so all breakpoints set at the same address
125 are duplicates of each other, even breakpoints set in the data
126 space (e.g., call dummy breakpoints placed on stack). This allows
127 a simplification in the spaces implementation: we avoid caring for
128 a many-many links between address and program spaces. Either
129 there's a single address space bound to the program space
130 (traditional unix/uClinux), or, in the DICOS case, the address
131 space bound to the program space is mostly ignored. */
132
133/* The program space structure. */
134
135struct program_space
136 {
137 /* Pointer to next in linked list. */
138 struct program_space *next;
139
140 /* Unique ID number. */
141 int num;
142
143 /* The main executable loaded into this program space. This is
144 managed by the exec target. */
145
146 /* The BFD handle for the main executable. */
147 bfd *ebfd;
148 /* The last-modified time, from when the exec was brought in. */
149 long ebfd_mtime;
150
151 /* The address space attached to this program space. More than one
152 program space may be bound to the same address space. In the
153 traditional unix-like debugging scenario, this will usually
154 match the address space bound to the inferior, and is mostly
155 used by the breakpoints module for address matches. If the
156 target shares a program space for all inferiors and breakpoints
157 are global, then this field is ignored (we don't currently
158 support inferiors sharing a program space if the target doesn't
159 make breakpoints global). */
160 struct address_space *aspace;
161
162 /* True if this program space's section offsets don't yet represent
163 the final offsets of the "live" address space (that is, the
164 section addresses still require the relocation offsets to be
165 applied, and hence we can't trust the section addresses for
166 anything that pokes at live memory). E.g., for qOffsets
167 targets, or for PIE executables, until we connect and ask the
168 target for the final relocation offsets, the symbols we've used
169 to set breakpoints point at the wrong addresses. */
170 int executing_startup;
171
56710373
PA
172 /* True if no breakpoints should be inserted in this program
173 space. */
174 int breakpoints_not_allowed;
175
6c95b8df
PA
176 /* The object file that the main symbol table was loaded from
177 (e.g. the argument to the "symbol-file" or "file" command). */
178 struct objfile *symfile_object_file;
179
180 /* All known objfiles are kept in a linked list. This points to
0df8b418 181 the head of this list. */
6c95b8df
PA
182 struct objfile *objfiles;
183
184 /* The set of target sections matching the sections mapped into
185 this program space. Managed by both exec_ops and solib.c. */
186 struct target_section_table target_sections;
187
188 /* List of shared objects mapped into this space. Managed by
189 solib.c. */
190 struct so_list *so_list;
191
2eff07b3
PP
192 /* Number of calls to solib_add. */
193 unsigned solib_add_generation;
194
edcc5120
TT
195 /* When an solib is added, it is also added to this vector. This
196 is so we can properly report solib changes to the user. */
197 VEC (so_list_ptr) *added_solibs;
198
199 /* When an solib is removed, its name is added to this vector.
200 This is so we can properly report solib changes to the user. */
201 VEC (char_ptr) *deleted_solibs;
202
6c95b8df
PA
203 /* Per pspace data-pointers required by other GDB modules. */
204 void **data;
205 unsigned num_data;
206 };
207
208/* The object file that the main symbol table was loaded from (e.g. the
209 argument to the "symbol-file" or "file" command). */
210
211#define symfile_objfile current_program_space->symfile_object_file
212
213/* All known objfiles are kept in a linked list. This points to the
0df8b418 214 root of this list. */
6c95b8df
PA
215#define object_files current_program_space->objfiles
216
217/* The set of target sections matching the sections mapped into the
218 current program space. */
219#define current_target_sections (&current_program_space->target_sections)
220
221/* The list of all program spaces. There's always at least one. */
222extern struct program_space *program_spaces;
223
224/* The current program space. This is always non-null. */
225extern struct program_space *current_program_space;
226
227#define ALL_PSPACES(pspace) \
228 for ((pspace) = program_spaces; (pspace) != NULL; (pspace) = (pspace)->next)
229
230/* Add a new empty program space, and assign ASPACE to it. Returns the
231 pointer to the new object. */
232extern struct program_space *add_program_space (struct address_space *aspace);
233
234/* Release PSPACE and removes it from the pspace list. */
235extern void remove_program_space (struct program_space *pspace);
236
237/* Returns the number of program spaces listed. */
238extern int number_of_program_spaces (void);
239
240/* Copies program space SRC to DEST. Copies the main executable file,
241 and the main symbol file. Returns DEST. */
242extern struct program_space *clone_program_space (struct program_space *dest,
243 struct program_space *src);
244
245/* Save the current program space so that it may be restored by a later
246 call to do_cleanups. Returns the struct cleanup pointer needed for
247 later doing the cleanup. */
248extern struct cleanup *save_current_program_space (void);
249
250/* Sets PSPACE as the current program space. This is usually used
251 instead of set_current_space_and_thread when the current
252 thread/inferior is not important for the operations that follow.
253 E.g., when accessing the raw symbol tables. If memory access is
254 required, then you should use switch_to_program_space_and_thread.
255 Otherwise, it is the caller's responsibility to make sure that the
256 currently selected inferior/thread matches the selected program
257 space. */
258extern void set_current_program_space (struct program_space *pspace);
259
260/* Saves the current thread (may be null), frame and program space in
261 the current cleanup chain. */
262extern struct cleanup *save_current_space_and_thread (void);
263
264/* Switches full context to program space PSPACE. Switches to the
265 first thread found bound to PSPACE. */
266extern void switch_to_program_space_and_thread (struct program_space *pspace);
267
268/* Create a new address space object, and add it to the list. */
269extern struct address_space *new_address_space (void);
270
271/* Maybe create a new address space object, and add it to the list, or
272 return a pointer to an existing address space, in case inferiors
273 share an address space. */
274extern struct address_space *maybe_new_address_space (void);
275
c0694254
PA
276/* Returns the integer address space id of ASPACE. */
277extern int address_space_num (struct address_space *aspace);
278
6c95b8df
PA
279/* Update all program spaces matching to address spaces. The user may
280 have created several program spaces, and loaded executables into
281 them before connecting to the target interface that will create the
282 inferiors. All that happens before GDB has a chance to know if the
283 inferiors will share an address space or not. Call this after
284 having connected to the target interface and having fetched the
285 target description, to fixup the program/address spaces
286 mappings. */
287extern void update_address_spaces (void);
288
289/* Prune away automatically added program spaces that aren't required
290 anymore. */
291extern void prune_program_spaces (void);
292
edcc5120
TT
293/* Reset saved solib data at the start of an solib event. This lets
294 us properly collect the data when calling solib_add, so it can then
295 later be printed. */
296extern void clear_program_space_solib_cache (struct program_space *);
297
6c95b8df
PA
298/* Keep a registry of per-pspace data-pointers required by other GDB
299 modules. */
300
301extern const struct program_space_data *register_program_space_data (void);
302extern const struct program_space_data *register_program_space_data_with_cleanup
303 (void (*cleanup) (struct program_space *, void *));
304extern void clear_program_space_data (struct program_space *pspace);
305extern void set_program_space_data (struct program_space *pspace,
3e43a32a
MS
306 const struct program_space_data *data,
307 void *value);
6c95b8df
PA
308extern void *program_space_data (struct program_space *pspace,
309 const struct program_space_data *data);
310
311#endif
This page took 0.361719 seconds and 4 git commands to generate.