1 |
24 |
jeremybenn |
/* Definitions for symbol file management in GDB.
|
2 |
|
|
|
3 |
|
|
Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001,
|
4 |
|
|
2002, 2003, 2004, 2007, 2008 Free Software Foundation, Inc.
|
5 |
|
|
|
6 |
|
|
This file is part of GDB.
|
7 |
|
|
|
8 |
|
|
This program is free software; you can redistribute it and/or modify
|
9 |
|
|
it under the terms of the GNU General Public License as published by
|
10 |
|
|
the Free Software Foundation; either version 3 of the License, or
|
11 |
|
|
(at your option) any later version.
|
12 |
|
|
|
13 |
|
|
This program is distributed in the hope that it will be useful,
|
14 |
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
15 |
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
16 |
|
|
GNU General Public License for more details.
|
17 |
|
|
|
18 |
|
|
You should have received a copy of the GNU General Public License
|
19 |
|
|
along with this program. If not, see <http://www.gnu.org/licenses/>. */
|
20 |
|
|
|
21 |
|
|
#if !defined (OBJFILES_H)
|
22 |
|
|
#define OBJFILES_H
|
23 |
|
|
|
24 |
|
|
#include "gdb_obstack.h" /* For obstack internals. */
|
25 |
|
|
#include "symfile.h" /* For struct psymbol_allocation_list */
|
26 |
|
|
|
27 |
|
|
struct bcache;
|
28 |
|
|
struct htab;
|
29 |
|
|
struct symtab;
|
30 |
|
|
struct objfile_data;
|
31 |
|
|
|
32 |
|
|
/* This structure maintains information on a per-objfile basis about the
|
33 |
|
|
"entry point" of the objfile, and the scope within which the entry point
|
34 |
|
|
exists. It is possible that gdb will see more than one objfile that is
|
35 |
|
|
executable, each with its own entry point.
|
36 |
|
|
|
37 |
|
|
For example, for dynamically linked executables in SVR4, the dynamic linker
|
38 |
|
|
code is contained within the shared C library, which is actually executable
|
39 |
|
|
and is run by the kernel first when an exec is done of a user executable
|
40 |
|
|
that is dynamically linked. The dynamic linker within the shared C library
|
41 |
|
|
then maps in the various program segments in the user executable and jumps
|
42 |
|
|
to the user executable's recorded entry point, as if the call had been made
|
43 |
|
|
directly by the kernel.
|
44 |
|
|
|
45 |
|
|
The traditional gdb method of using this info was to use the
|
46 |
|
|
recorded entry point to set the entry-file's lowpc and highpc from
|
47 |
|
|
the debugging information, where these values are the starting
|
48 |
|
|
address (inclusive) and ending address (exclusive) of the
|
49 |
|
|
instruction space in the executable which correspond to the
|
50 |
|
|
"startup file", I.E. crt0.o in most cases. This file is assumed to
|
51 |
|
|
be a startup file and frames with pc's inside it are treated as
|
52 |
|
|
nonexistent. Setting these variables is necessary so that
|
53 |
|
|
backtraces do not fly off the bottom of the stack.
|
54 |
|
|
|
55 |
|
|
NOTE: cagney/2003-09-09: It turns out that this "traditional"
|
56 |
|
|
method doesn't work. Corinna writes: ``It turns out that the call
|
57 |
|
|
to test for "inside entry file" destroys a meaningful backtrace
|
58 |
|
|
under some conditions. E. g. the backtrace tests in the asm-source
|
59 |
|
|
testcase are broken for some targets. In this test the functions
|
60 |
|
|
are all implemented as part of one file and the testcase is not
|
61 |
|
|
necessarily linked with a start file (depending on the target).
|
62 |
|
|
What happens is, that the first frame is printed normaly and
|
63 |
|
|
following frames are treated as being inside the enttry file then.
|
64 |
|
|
This way, only the #0 frame is printed in the backtrace output.''
|
65 |
|
|
Ref "frame.c" "NOTE: vinschen/2003-04-01".
|
66 |
|
|
|
67 |
|
|
Gdb also supports an alternate method to avoid running off the bottom
|
68 |
|
|
of the stack.
|
69 |
|
|
|
70 |
|
|
There are two frames that are "special", the frame for the function
|
71 |
|
|
containing the process entry point, since it has no predecessor frame,
|
72 |
|
|
and the frame for the function containing the user code entry point
|
73 |
|
|
(the main() function), since all the predecessor frames are for the
|
74 |
|
|
process startup code. Since we have no guarantee that the linked
|
75 |
|
|
in startup modules have any debugging information that gdb can use,
|
76 |
|
|
we need to avoid following frame pointers back into frames that might
|
77 |
|
|
have been built in the startup code, as we might get hopelessly
|
78 |
|
|
confused. However, we almost always have debugging information
|
79 |
|
|
available for main().
|
80 |
|
|
|
81 |
|
|
These variables are used to save the range of PC values which are
|
82 |
|
|
valid within the main() function and within the function containing
|
83 |
|
|
the process entry point. If we always consider the frame for
|
84 |
|
|
main() as the outermost frame when debugging user code, and the
|
85 |
|
|
frame for the process entry point function as the outermost frame
|
86 |
|
|
when debugging startup code, then all we have to do is have
|
87 |
|
|
DEPRECATED_FRAME_CHAIN_VALID return false whenever a frame's
|
88 |
|
|
current PC is within the range specified by these variables. In
|
89 |
|
|
essence, we set "ceilings" in the frame chain beyond which we will
|
90 |
|
|
not proceed when following the frame chain back up the stack.
|
91 |
|
|
|
92 |
|
|
A nice side effect is that we can still debug startup code without
|
93 |
|
|
running off the end of the frame chain, assuming that we have usable
|
94 |
|
|
debugging information in the startup modules, and if we choose to not
|
95 |
|
|
use the block at main, or can't find it for some reason, everything
|
96 |
|
|
still works as before. And if we have no startup code debugging
|
97 |
|
|
information but we do have usable information for main(), backtraces
|
98 |
|
|
from user code don't go wandering off into the startup code. */
|
99 |
|
|
|
100 |
|
|
struct entry_info
|
101 |
|
|
{
|
102 |
|
|
|
103 |
|
|
/* The value we should use for this objects entry point.
|
104 |
|
|
The illegal/unknown value needs to be something other than 0, ~0
|
105 |
|
|
for instance, which is much less likely than 0. */
|
106 |
|
|
|
107 |
|
|
CORE_ADDR entry_point;
|
108 |
|
|
|
109 |
|
|
#define INVALID_ENTRY_POINT (~0) /* ~0 will not be in any file, we hope. */
|
110 |
|
|
|
111 |
|
|
};
|
112 |
|
|
|
113 |
|
|
/* Sections in an objfile.
|
114 |
|
|
|
115 |
|
|
It is strange that we have both this notion of "sections"
|
116 |
|
|
and the one used by section_offsets. Section as used
|
117 |
|
|
here, (currently at least) means a BFD section, and the sections
|
118 |
|
|
are set up from the BFD sections in allocate_objfile.
|
119 |
|
|
|
120 |
|
|
The sections in section_offsets have their meaning determined by
|
121 |
|
|
the symbol format, and they are set up by the sym_offsets function
|
122 |
|
|
for that symbol file format.
|
123 |
|
|
|
124 |
|
|
I'm not sure this could or should be changed, however. */
|
125 |
|
|
|
126 |
|
|
struct obj_section
|
127 |
|
|
{
|
128 |
|
|
CORE_ADDR addr; /* lowest address in section */
|
129 |
|
|
CORE_ADDR endaddr; /* 1+highest address in section */
|
130 |
|
|
|
131 |
|
|
/* This field is being used for nefarious purposes by syms_from_objfile.
|
132 |
|
|
It is said to be redundant with section_offsets; it's not really being
|
133 |
|
|
used that way, however, it's some sort of hack I don't understand
|
134 |
|
|
and am not going to try to eliminate (yet, anyway). FIXME.
|
135 |
|
|
|
136 |
|
|
It was documented as "offset between (end)addr and actual memory
|
137 |
|
|
addresses", but that's not true; addr & endaddr are actual memory
|
138 |
|
|
addresses. */
|
139 |
|
|
CORE_ADDR offset;
|
140 |
|
|
|
141 |
|
|
struct bfd_section *the_bfd_section; /* BFD section pointer */
|
142 |
|
|
|
143 |
|
|
/* Objfile this section is part of. */
|
144 |
|
|
struct objfile *objfile;
|
145 |
|
|
|
146 |
|
|
/* True if this "overlay section" is mapped into an "overlay region". */
|
147 |
|
|
int ovly_mapped;
|
148 |
|
|
};
|
149 |
|
|
|
150 |
|
|
|
151 |
|
|
/* The "objstats" structure provides a place for gdb to record some
|
152 |
|
|
interesting information about its internal state at runtime, on a
|
153 |
|
|
per objfile basis, such as information about the number of symbols
|
154 |
|
|
read, size of string table (if any), etc. */
|
155 |
|
|
|
156 |
|
|
struct objstats
|
157 |
|
|
{
|
158 |
|
|
int n_minsyms; /* Number of minimal symbols read */
|
159 |
|
|
int n_psyms; /* Number of partial symbols read */
|
160 |
|
|
int n_syms; /* Number of full symbols read */
|
161 |
|
|
int n_stabs; /* Number of ".stabs" read (if applicable) */
|
162 |
|
|
int n_types; /* Number of types */
|
163 |
|
|
int sz_strtab; /* Size of stringtable, (if applicable) */
|
164 |
|
|
};
|
165 |
|
|
|
166 |
|
|
#define OBJSTAT(objfile, expr) (objfile -> stats.expr)
|
167 |
|
|
#define OBJSTATS struct objstats stats
|
168 |
|
|
extern void print_objfile_statistics (void);
|
169 |
|
|
extern void print_symbol_bcache_statistics (void);
|
170 |
|
|
|
171 |
|
|
/* Number of entries in the minimal symbol hash table. */
|
172 |
|
|
#define MINIMAL_SYMBOL_HASH_SIZE 2039
|
173 |
|
|
|
174 |
|
|
/* Master structure for keeping track of each file from which
|
175 |
|
|
gdb reads symbols. There are several ways these get allocated: 1.
|
176 |
|
|
The main symbol file, symfile_objfile, set by the symbol-file command,
|
177 |
|
|
2. Additional symbol files added by the add-symbol-file command,
|
178 |
|
|
3. Shared library objfiles, added by ADD_SOLIB, 4. symbol files
|
179 |
|
|
for modules that were loaded when GDB attached to a remote system
|
180 |
|
|
(see remote-vx.c). */
|
181 |
|
|
|
182 |
|
|
struct objfile
|
183 |
|
|
{
|
184 |
|
|
|
185 |
|
|
/* All struct objfile's are chained together by their next pointers.
|
186 |
|
|
The global variable "object_files" points to the first link in this
|
187 |
|
|
chain.
|
188 |
|
|
|
189 |
|
|
FIXME: There is a problem here if the objfile is reusable, and if
|
190 |
|
|
multiple users are to be supported. The problem is that the objfile
|
191 |
|
|
list is linked through a member of the objfile struct itself, which
|
192 |
|
|
is only valid for one gdb process. The list implementation needs to
|
193 |
|
|
be changed to something like:
|
194 |
|
|
|
195 |
|
|
struct list {struct list *next; struct objfile *objfile};
|
196 |
|
|
|
197 |
|
|
where the list structure is completely maintained separately within
|
198 |
|
|
each gdb process. */
|
199 |
|
|
|
200 |
|
|
struct objfile *next;
|
201 |
|
|
|
202 |
|
|
/* The object file's name, tilde-expanded and absolute.
|
203 |
|
|
Malloc'd; free it if you free this struct. */
|
204 |
|
|
|
205 |
|
|
char *name;
|
206 |
|
|
|
207 |
|
|
/* Some flag bits for this objfile. */
|
208 |
|
|
|
209 |
|
|
unsigned short flags;
|
210 |
|
|
|
211 |
|
|
/* Each objfile points to a linked list of symtabs derived from this file,
|
212 |
|
|
one symtab structure for each compilation unit (source file). Each link
|
213 |
|
|
in the symtab list contains a backpointer to this objfile. */
|
214 |
|
|
|
215 |
|
|
struct symtab *symtabs;
|
216 |
|
|
|
217 |
|
|
/* Each objfile points to a linked list of partial symtabs derived from
|
218 |
|
|
this file, one partial symtab structure for each compilation unit
|
219 |
|
|
(source file). */
|
220 |
|
|
|
221 |
|
|
struct partial_symtab *psymtabs;
|
222 |
|
|
|
223 |
|
|
/* List of freed partial symtabs, available for re-use */
|
224 |
|
|
|
225 |
|
|
struct partial_symtab *free_psymtabs;
|
226 |
|
|
|
227 |
|
|
/* The object file's BFD. Can be null if the objfile contains only
|
228 |
|
|
minimal symbols, e.g. the run time common symbols for SunOS4. */
|
229 |
|
|
|
230 |
|
|
bfd *obfd;
|
231 |
|
|
|
232 |
|
|
/* The modification timestamp of the object file, as of the last time
|
233 |
|
|
we read its symbols. */
|
234 |
|
|
|
235 |
|
|
long mtime;
|
236 |
|
|
|
237 |
|
|
/* Obstack to hold objects that should be freed when we load a new symbol
|
238 |
|
|
table from this object file. */
|
239 |
|
|
|
240 |
|
|
struct obstack objfile_obstack;
|
241 |
|
|
|
242 |
|
|
/* A byte cache where we can stash arbitrary "chunks" of bytes that
|
243 |
|
|
will not change. */
|
244 |
|
|
|
245 |
|
|
struct bcache *psymbol_cache; /* Byte cache for partial syms */
|
246 |
|
|
struct bcache *macro_cache; /* Byte cache for macros */
|
247 |
|
|
|
248 |
|
|
/* Hash table for mapping symbol names to demangled names. Each
|
249 |
|
|
entry in the hash table is actually two consecutive strings,
|
250 |
|
|
both null-terminated; the first one is a mangled or linkage
|
251 |
|
|
name, and the second is the demangled name or just a zero byte
|
252 |
|
|
if the name doesn't demangle. */
|
253 |
|
|
struct htab *demangled_names_hash;
|
254 |
|
|
|
255 |
|
|
/* Vectors of all partial symbols read in from file. The actual data
|
256 |
|
|
is stored in the objfile_obstack. */
|
257 |
|
|
|
258 |
|
|
struct psymbol_allocation_list global_psymbols;
|
259 |
|
|
struct psymbol_allocation_list static_psymbols;
|
260 |
|
|
|
261 |
|
|
/* Each file contains a pointer to an array of minimal symbols for all
|
262 |
|
|
global symbols that are defined within the file. The array is terminated
|
263 |
|
|
by a "null symbol", one that has a NULL pointer for the name and a zero
|
264 |
|
|
value for the address. This makes it easy to walk through the array
|
265 |
|
|
when passed a pointer to somewhere in the middle of it. There is also
|
266 |
|
|
a count of the number of symbols, which does not include the terminating
|
267 |
|
|
null symbol. The array itself, as well as all the data that it points
|
268 |
|
|
to, should be allocated on the objfile_obstack for this file. */
|
269 |
|
|
|
270 |
|
|
struct minimal_symbol *msymbols;
|
271 |
|
|
int minimal_symbol_count;
|
272 |
|
|
|
273 |
|
|
/* This is a hash table used to index the minimal symbols by name. */
|
274 |
|
|
|
275 |
|
|
struct minimal_symbol *msymbol_hash[MINIMAL_SYMBOL_HASH_SIZE];
|
276 |
|
|
|
277 |
|
|
/* This hash table is used to index the minimal symbols by their
|
278 |
|
|
demangled names. */
|
279 |
|
|
|
280 |
|
|
struct minimal_symbol *msymbol_demangled_hash[MINIMAL_SYMBOL_HASH_SIZE];
|
281 |
|
|
|
282 |
|
|
/* The mmalloc() malloc-descriptor for this objfile if we are using
|
283 |
|
|
the memory mapped malloc() package to manage storage for this objfile's
|
284 |
|
|
data. NULL if we are not. */
|
285 |
|
|
|
286 |
|
|
void *md;
|
287 |
|
|
|
288 |
|
|
/* The file descriptor that was used to obtain the mmalloc descriptor
|
289 |
|
|
for this objfile. If we call mmalloc_detach with the malloc descriptor
|
290 |
|
|
we should then close this file descriptor. */
|
291 |
|
|
|
292 |
|
|
int mmfd;
|
293 |
|
|
|
294 |
|
|
/* Structure which keeps track of functions that manipulate objfile's
|
295 |
|
|
of the same type as this objfile. I.E. the function to read partial
|
296 |
|
|
symbols for example. Note that this structure is in statically
|
297 |
|
|
allocated memory, and is shared by all objfiles that use the
|
298 |
|
|
object module reader of this type. */
|
299 |
|
|
|
300 |
|
|
struct sym_fns *sf;
|
301 |
|
|
|
302 |
|
|
/* The per-objfile information about the entry point, the scope (file/func)
|
303 |
|
|
containing the entry point, and the scope of the user's main() func. */
|
304 |
|
|
|
305 |
|
|
struct entry_info ei;
|
306 |
|
|
|
307 |
|
|
/* Information about stabs. Will be filled in with a dbx_symfile_info
|
308 |
|
|
struct by those readers that need it. */
|
309 |
|
|
/* NOTE: cagney/2004-10-23: This has been replaced by per-objfile
|
310 |
|
|
data points implemented using "data" and "num_data" below. For
|
311 |
|
|
an example of how to use this replacement, see "objfile_data"
|
312 |
|
|
in "mips-tdep.c". */
|
313 |
|
|
|
314 |
|
|
struct dbx_symfile_info *deprecated_sym_stab_info;
|
315 |
|
|
|
316 |
|
|
/* Hook for information for use by the symbol reader (currently used
|
317 |
|
|
for information shared by sym_init and sym_read). It is
|
318 |
|
|
typically a pointer to malloc'd memory. The symbol reader's finish
|
319 |
|
|
function is responsible for freeing the memory thusly allocated. */
|
320 |
|
|
/* NOTE: cagney/2004-10-23: This has been replaced by per-objfile
|
321 |
|
|
data points implemented using "data" and "num_data" below. For
|
322 |
|
|
an example of how to use this replacement, see "objfile_data"
|
323 |
|
|
in "mips-tdep.c". */
|
324 |
|
|
|
325 |
|
|
void *deprecated_sym_private;
|
326 |
|
|
|
327 |
|
|
/* Hook for target-architecture-specific information. This must
|
328 |
|
|
point to memory allocated on one of the obstacks in this objfile,
|
329 |
|
|
so that it gets freed automatically when reading a new object
|
330 |
|
|
file. */
|
331 |
|
|
|
332 |
|
|
void *deprecated_obj_private;
|
333 |
|
|
|
334 |
|
|
/* Per objfile data-pointers required by other GDB modules. */
|
335 |
|
|
/* FIXME: kettenis/20030711: This mechanism could replace
|
336 |
|
|
deprecated_sym_stab_info, deprecated_sym_private and
|
337 |
|
|
deprecated_obj_private entirely. */
|
338 |
|
|
|
339 |
|
|
void **data;
|
340 |
|
|
unsigned num_data;
|
341 |
|
|
|
342 |
|
|
/* Set of relocation offsets to apply to each section.
|
343 |
|
|
Currently on the objfile_obstack (which makes no sense, but I'm
|
344 |
|
|
not sure it's harming anything).
|
345 |
|
|
|
346 |
|
|
These offsets indicate that all symbols (including partial and
|
347 |
|
|
minimal symbols) which have been read have been relocated by this
|
348 |
|
|
much. Symbols which are yet to be read need to be relocated by
|
349 |
|
|
it. */
|
350 |
|
|
|
351 |
|
|
struct section_offsets *section_offsets;
|
352 |
|
|
int num_sections;
|
353 |
|
|
|
354 |
|
|
/* Indexes in the section_offsets array. These are initialized by the
|
355 |
|
|
*_symfile_offsets() family of functions (som_symfile_offsets,
|
356 |
|
|
xcoff_symfile_offsets, default_symfile_offsets). In theory they
|
357 |
|
|
should correspond to the section indexes used by bfd for the
|
358 |
|
|
current objfile. The exception to this for the time being is the
|
359 |
|
|
SOM version. */
|
360 |
|
|
|
361 |
|
|
int sect_index_text;
|
362 |
|
|
int sect_index_data;
|
363 |
|
|
int sect_index_bss;
|
364 |
|
|
int sect_index_rodata;
|
365 |
|
|
|
366 |
|
|
/* These pointers are used to locate the section table, which
|
367 |
|
|
among other things, is used to map pc addresses into sections.
|
368 |
|
|
SECTIONS points to the first entry in the table, and
|
369 |
|
|
SECTIONS_END points to the first location past the last entry
|
370 |
|
|
in the table. Currently the table is stored on the
|
371 |
|
|
objfile_obstack (which makes no sense, but I'm not sure it's
|
372 |
|
|
harming anything). */
|
373 |
|
|
|
374 |
|
|
struct obj_section
|
375 |
|
|
*sections, *sections_end;
|
376 |
|
|
|
377 |
|
|
/* Link to objfile that contains the debug symbols for this one.
|
378 |
|
|
One is loaded if this file has an debug link to an existing
|
379 |
|
|
debug file with the right checksum */
|
380 |
|
|
struct objfile *separate_debug_objfile;
|
381 |
|
|
|
382 |
|
|
/* If this is a separate debug object, this is used as a link to the
|
383 |
|
|
actual executable objfile. */
|
384 |
|
|
struct objfile *separate_debug_objfile_backlink;
|
385 |
|
|
|
386 |
|
|
/* Place to stash various statistics about this objfile */
|
387 |
|
|
OBJSTATS;
|
388 |
|
|
|
389 |
|
|
/* A symtab that the C++ code uses to stash special symbols
|
390 |
|
|
associated to namespaces. */
|
391 |
|
|
|
392 |
|
|
/* FIXME/carlton-2003-06-27: Delete this in a few years once
|
393 |
|
|
"possible namespace symbols" go away. */
|
394 |
|
|
struct symtab *cp_namespace_symtab;
|
395 |
|
|
};
|
396 |
|
|
|
397 |
|
|
/* Defines for the objfile flag word. */
|
398 |
|
|
|
399 |
|
|
/* When using mapped/remapped predigested gdb symbol information, we need
|
400 |
|
|
a flag that indicates that we have previously done an initial symbol
|
401 |
|
|
table read from this particular objfile. We can't just look for the
|
402 |
|
|
absence of any of the three symbol tables (msymbols, psymtab, symtab)
|
403 |
|
|
because if the file has no symbols for example, none of these will
|
404 |
|
|
exist. */
|
405 |
|
|
|
406 |
|
|
#define OBJF_SYMS (1 << 1) /* Have tried to read symbols */
|
407 |
|
|
|
408 |
|
|
/* When an object file has its functions reordered (currently Irix-5.2
|
409 |
|
|
shared libraries exhibit this behaviour), we will need an expensive
|
410 |
|
|
algorithm to locate a partial symtab or symtab via an address.
|
411 |
|
|
To avoid this penalty for normal object files, we use this flag,
|
412 |
|
|
whose setting is determined upon symbol table read in. */
|
413 |
|
|
|
414 |
|
|
#define OBJF_REORDERED (1 << 2) /* Functions are reordered */
|
415 |
|
|
|
416 |
|
|
/* Distinguish between an objfile for a shared library and a "vanilla"
|
417 |
|
|
objfile. (If not set, the objfile may still actually be a solib.
|
418 |
|
|
This can happen if the user created the objfile by using the
|
419 |
|
|
add-symbol-file command. GDB doesn't in that situation actually
|
420 |
|
|
check whether the file is a solib. Rather, the target's
|
421 |
|
|
implementation of the solib interface is responsible for setting
|
422 |
|
|
this flag when noticing solibs used by an inferior.) */
|
423 |
|
|
|
424 |
|
|
#define OBJF_SHARED (1 << 3) /* From a shared library */
|
425 |
|
|
|
426 |
|
|
/* User requested that this objfile be read in it's entirety. */
|
427 |
|
|
|
428 |
|
|
#define OBJF_READNOW (1 << 4) /* Immediate full read */
|
429 |
|
|
|
430 |
|
|
/* This objfile was created because the user explicitly caused it
|
431 |
|
|
(e.g., used the add-symbol-file command). This bit offers a way
|
432 |
|
|
for run_command to remove old objfile entries which are no longer
|
433 |
|
|
valid (i.e., are associated with an old inferior), but to preserve
|
434 |
|
|
ones that the user explicitly loaded via the add-symbol-file
|
435 |
|
|
command. */
|
436 |
|
|
|
437 |
|
|
#define OBJF_USERLOADED (1 << 5) /* User loaded */
|
438 |
|
|
|
439 |
|
|
/* The object file that the main symbol table was loaded from (e.g. the
|
440 |
|
|
argument to the "symbol-file" or "file" command). */
|
441 |
|
|
|
442 |
|
|
extern struct objfile *symfile_objfile;
|
443 |
|
|
|
444 |
|
|
/* The object file that contains the runtime common minimal symbols
|
445 |
|
|
for SunOS4. Note that this objfile has no associated BFD. */
|
446 |
|
|
|
447 |
|
|
extern struct objfile *rt_common_objfile;
|
448 |
|
|
|
449 |
|
|
/* When we need to allocate a new type, we need to know which objfile_obstack
|
450 |
|
|
to allocate the type on, since there is one for each objfile. The places
|
451 |
|
|
where types are allocated are deeply buried in function call hierarchies
|
452 |
|
|
which know nothing about objfiles, so rather than trying to pass a
|
453 |
|
|
particular objfile down to them, we just do an end run around them and
|
454 |
|
|
set current_objfile to be whatever objfile we expect to be using at the
|
455 |
|
|
time types are being allocated. For instance, when we start reading
|
456 |
|
|
symbols for a particular objfile, we set current_objfile to point to that
|
457 |
|
|
objfile, and when we are done, we set it back to NULL, to ensure that we
|
458 |
|
|
never put a type someplace other than where we are expecting to put it.
|
459 |
|
|
FIXME: Maybe we should review the entire type handling system and
|
460 |
|
|
see if there is a better way to avoid this problem. */
|
461 |
|
|
|
462 |
|
|
extern struct objfile *current_objfile;
|
463 |
|
|
|
464 |
|
|
/* All known objfiles are kept in a linked list. This points to the
|
465 |
|
|
root of this list. */
|
466 |
|
|
|
467 |
|
|
extern struct objfile *object_files;
|
468 |
|
|
|
469 |
|
|
/* Declarations for functions defined in objfiles.c */
|
470 |
|
|
|
471 |
|
|
extern struct objfile *allocate_objfile (bfd *, int);
|
472 |
|
|
|
473 |
|
|
extern void init_entry_point_info (struct objfile *);
|
474 |
|
|
|
475 |
|
|
extern CORE_ADDR entry_point_address (void);
|
476 |
|
|
|
477 |
|
|
extern int build_objfile_section_table (struct objfile *);
|
478 |
|
|
|
479 |
|
|
extern void terminate_minimal_symbol_table (struct objfile *objfile);
|
480 |
|
|
|
481 |
|
|
extern void put_objfile_before (struct objfile *, struct objfile *);
|
482 |
|
|
|
483 |
|
|
extern void objfile_to_front (struct objfile *);
|
484 |
|
|
|
485 |
|
|
extern void unlink_objfile (struct objfile *);
|
486 |
|
|
|
487 |
|
|
extern void free_objfile (struct objfile *);
|
488 |
|
|
|
489 |
|
|
extern struct cleanup *make_cleanup_free_objfile (struct objfile *);
|
490 |
|
|
|
491 |
|
|
extern void free_all_objfiles (void);
|
492 |
|
|
|
493 |
|
|
extern void objfile_relocate (struct objfile *, struct section_offsets *);
|
494 |
|
|
|
495 |
|
|
extern int have_partial_symbols (void);
|
496 |
|
|
|
497 |
|
|
extern int have_full_symbols (void);
|
498 |
|
|
|
499 |
|
|
/* This operation deletes all objfile entries that represent solibs that
|
500 |
|
|
weren't explicitly loaded by the user, via e.g., the add-symbol-file
|
501 |
|
|
command.
|
502 |
|
|
*/
|
503 |
|
|
extern void objfile_purge_solibs (void);
|
504 |
|
|
|
505 |
|
|
/* Functions for dealing with the minimal symbol table, really a misc
|
506 |
|
|
address<->symbol mapping for things we don't have debug symbols for. */
|
507 |
|
|
|
508 |
|
|
extern int have_minimal_symbols (void);
|
509 |
|
|
|
510 |
|
|
extern struct obj_section *find_pc_section (CORE_ADDR pc);
|
511 |
|
|
|
512 |
|
|
extern struct obj_section *find_pc_sect_section (CORE_ADDR pc,
|
513 |
|
|
asection * section);
|
514 |
|
|
|
515 |
|
|
extern int in_plt_section (CORE_ADDR, char *);
|
516 |
|
|
|
517 |
|
|
/* Keep a registry of per-objfile data-pointers required by other GDB
|
518 |
|
|
modules. */
|
519 |
|
|
|
520 |
|
|
extern const struct objfile_data *register_objfile_data (void);
|
521 |
|
|
extern void clear_objfile_data (struct objfile *objfile);
|
522 |
|
|
extern void set_objfile_data (struct objfile *objfile,
|
523 |
|
|
const struct objfile_data *data, void *value);
|
524 |
|
|
extern void *objfile_data (struct objfile *objfile,
|
525 |
|
|
const struct objfile_data *data);
|
526 |
|
|
|
527 |
|
|
|
528 |
|
|
/* Traverse all object files. ALL_OBJFILES_SAFE works even if you delete
|
529 |
|
|
the objfile during the traversal. */
|
530 |
|
|
|
531 |
|
|
#define ALL_OBJFILES(obj) \
|
532 |
|
|
for ((obj) = object_files; (obj) != NULL; (obj) = (obj)->next)
|
533 |
|
|
|
534 |
|
|
#define ALL_OBJFILES_SAFE(obj,nxt) \
|
535 |
|
|
for ((obj) = object_files; \
|
536 |
|
|
(obj) != NULL? ((nxt)=(obj)->next,1) :0; \
|
537 |
|
|
(obj) = (nxt))
|
538 |
|
|
|
539 |
|
|
/* Traverse all symtabs in one objfile. */
|
540 |
|
|
|
541 |
|
|
#define ALL_OBJFILE_SYMTABS(objfile, s) \
|
542 |
|
|
for ((s) = (objfile) -> symtabs; (s) != NULL; (s) = (s) -> next)
|
543 |
|
|
|
544 |
|
|
/* Traverse all psymtabs in one objfile. */
|
545 |
|
|
|
546 |
|
|
#define ALL_OBJFILE_PSYMTABS(objfile, p) \
|
547 |
|
|
for ((p) = (objfile) -> psymtabs; (p) != NULL; (p) = (p) -> next)
|
548 |
|
|
|
549 |
|
|
/* Traverse all minimal symbols in one objfile. */
|
550 |
|
|
|
551 |
|
|
#define ALL_OBJFILE_MSYMBOLS(objfile, m) \
|
552 |
|
|
for ((m) = (objfile) -> msymbols; DEPRECATED_SYMBOL_NAME(m) != NULL; (m)++)
|
553 |
|
|
|
554 |
|
|
/* Traverse all symtabs in all objfiles. */
|
555 |
|
|
|
556 |
|
|
#define ALL_SYMTABS(objfile, s) \
|
557 |
|
|
ALL_OBJFILES (objfile) \
|
558 |
|
|
ALL_OBJFILE_SYMTABS (objfile, s)
|
559 |
|
|
|
560 |
|
|
/* Traverse all symtabs in all objfiles, skipping included files
|
561 |
|
|
(which share a blockvector with their primary symtab). */
|
562 |
|
|
|
563 |
|
|
#define ALL_PRIMARY_SYMTABS(objfile, s) \
|
564 |
|
|
ALL_OBJFILES (objfile) \
|
565 |
|
|
ALL_OBJFILE_SYMTABS (objfile, s) \
|
566 |
|
|
if ((s)->primary)
|
567 |
|
|
|
568 |
|
|
/* Traverse all psymtabs in all objfiles. */
|
569 |
|
|
|
570 |
|
|
#define ALL_PSYMTABS(objfile, p) \
|
571 |
|
|
ALL_OBJFILES (objfile) \
|
572 |
|
|
ALL_OBJFILE_PSYMTABS (objfile, p)
|
573 |
|
|
|
574 |
|
|
/* Traverse all minimal symbols in all objfiles. */
|
575 |
|
|
|
576 |
|
|
#define ALL_MSYMBOLS(objfile, m) \
|
577 |
|
|
ALL_OBJFILES (objfile) \
|
578 |
|
|
ALL_OBJFILE_MSYMBOLS (objfile, m)
|
579 |
|
|
|
580 |
|
|
#define ALL_OBJFILE_OSECTIONS(objfile, osect) \
|
581 |
|
|
for (osect = objfile->sections; osect < objfile->sections_end; osect++)
|
582 |
|
|
|
583 |
|
|
#define ALL_OBJSECTIONS(objfile, osect) \
|
584 |
|
|
ALL_OBJFILES (objfile) \
|
585 |
|
|
ALL_OBJFILE_OSECTIONS (objfile, osect)
|
586 |
|
|
|
587 |
|
|
#define SECT_OFF_DATA(objfile) \
|
588 |
|
|
((objfile->sect_index_data == -1) \
|
589 |
|
|
? (internal_error (__FILE__, __LINE__, _("sect_index_data not initialized")), -1) \
|
590 |
|
|
: objfile->sect_index_data)
|
591 |
|
|
|
592 |
|
|
#define SECT_OFF_RODATA(objfile) \
|
593 |
|
|
((objfile->sect_index_rodata == -1) \
|
594 |
|
|
? (internal_error (__FILE__, __LINE__, _("sect_index_rodata not initialized")), -1) \
|
595 |
|
|
: objfile->sect_index_rodata)
|
596 |
|
|
|
597 |
|
|
#define SECT_OFF_TEXT(objfile) \
|
598 |
|
|
((objfile->sect_index_text == -1) \
|
599 |
|
|
? (internal_error (__FILE__, __LINE__, _("sect_index_text not initialized")), -1) \
|
600 |
|
|
: objfile->sect_index_text)
|
601 |
|
|
|
602 |
|
|
/* Sometimes the .bss section is missing from the objfile, so we don't
|
603 |
|
|
want to die here. Let the users of SECT_OFF_BSS deal with an
|
604 |
|
|
uninitialized section index. */
|
605 |
|
|
#define SECT_OFF_BSS(objfile) (objfile)->sect_index_bss
|
606 |
|
|
|
607 |
|
|
#endif /* !defined (OBJFILES_H) */
|