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