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