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