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