-struct obj_section {
- CORE_ADDR addr; /* lowest address in section */
- CORE_ADDR endaddr; /* 1+highest address in section */
-
- /* This field is being used for nefarious purposes by syms_from_objfile.
- It is said to be redundant with section_offsets; it's not really being
- used that way, however, it's some sort of hack I don't understand
- and am not going to try to eliminate (yet, anyway). FIXME.
-
- It was documented as "offset between (end)addr and actual memory
- addresses", but that's not true; addr & endaddr are actual memory
- addresses. */
- CORE_ADDR offset;
-
- sec_ptr sec_ptr; /* BFD section pointer */
-
- /* Objfile this section is part of. Not currently used, but I'm sure
- that someone will want the bfd that the sec_ptr goes with or something
- like that before long. */
- struct objfile *objfile;
-};
-
-/* Master structure for keeping track of each input file from which
- gdb reads symbols. One of these is allocated for each such file we
- access, e.g. the exec_file, symbol_file, and any shared library object
- files. */
+struct obj_section
+ {
+ CORE_ADDR addr; /* lowest address in section */
+ CORE_ADDR endaddr; /* 1+highest address in section */
+
+ /* This field is being used for nefarious purposes by syms_from_objfile.
+ It is said to be redundant with section_offsets; it's not really being
+ used that way, however, it's some sort of hack I don't understand
+ and am not going to try to eliminate (yet, anyway). FIXME.
+
+ It was documented as "offset between (end)addr and actual memory
+ addresses", but that's not true; addr & endaddr are actual memory
+ addresses. */
+ CORE_ADDR offset;
+
+ sec_ptr the_bfd_section; /* BFD section pointer */
+
+ /* Objfile this section is part of. */
+ struct objfile *objfile;
+
+ /* True if this "overlay section" is mapped into an "overlay region". */
+ int ovly_mapped;
+ };
+
+/* An import entry contains information about a symbol that
+ is used in this objfile but not defined in it, and so needs
+ to be imported from some other objfile */
+/* Currently we just store the name; no attributes. 1997-08-05 */
+typedef char *ImportEntry;
+
+
+/* An export entry contains information about a symbol that
+ is defined in this objfile and available for use in other
+ objfiles */
+typedef struct
+ {
+ char *name; /* name of exported symbol */
+ int address; /* offset subject to relocation */
+ /* Currently no other attributes 1997-08-05 */
+ }
+ExportEntry;
+
+
+/* The "objstats" structure provides a place for gdb to record some
+ interesting information about its internal state at runtime, on a
+ per objfile basis, such as information about the number of symbols
+ read, size of string table (if any), etc. */
+
+struct objstats
+ {
+ int n_minsyms; /* Number of minimal symbols read */
+ int n_psyms; /* Number of partial symbols read */
+ int n_syms; /* Number of full symbols read */
+ int n_stabs; /* Number of ".stabs" read (if applicable) */
+ int n_types; /* Number of types */
+ int sz_strtab; /* Size of stringtable, (if applicable) */
+ };
+
+#define OBJSTAT(objfile, expr) (objfile -> stats.expr)
+#define OBJSTATS struct objstats stats
+extern void print_objfile_statistics (void);
+extern void print_symbol_bcache_statistics (void);
+
+/* Number of entries in the minimal symbol hash table. */
+#define MINIMAL_SYMBOL_HASH_SIZE 2039
+
+/* Master structure for keeping track of each file from which
+ gdb reads symbols. There are several ways these get allocated: 1.
+ The main symbol file, symfile_objfile, set by the symbol-file command,
+ 2. Additional symbol files added by the add-symbol-file command,
+ 3. Shared library objfiles, added by ADD_SOLIB, 4. symbol files
+ for modules that were loaded when GDB attached to a remote system
+ (see remote-vx.c). */