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