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