gdb/objfiles.h

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