* configure: Ignore new autoconf configure options.
[binutils-gdb.git] / gdb / objfiles.h
index 50226ff47e779ffeceddf033b4103155799fcf0d..bb1df89b2232037c1071d133e1963b611840d813 100644 (file)
@@ -1,5 +1,5 @@
 /* Definitions for symbol file management in GDB.
-   Copyright (C) 1992 Free Software Foundation, Inc.
+   Copyright (C) 1992, 1993, 1994, 1995 Free Software Foundation, Inc.
 
 This file is part of GDB.
 
@@ -15,7 +15,7 @@ GNU General Public License for more details.
 
 You should have received a copy of the GNU General Public License
 along with this program; if not, write to the Free Software
-Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.  */
+Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
 
 #if !defined (OBJFILES_H)
 #define OBJFILES_H
@@ -23,7 +23,7 @@ Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.  */
 /* This structure maintains information on a per-objfile basis about the
    "entry point" of the objfile, and the scope within which the entry point
    exists.  It is possible that gdb will see more than one objfile that is
-   executable, each with it's own entry point.
+   executable, each with its own entry point.
 
    For example, for dynamically linked executables in SVR4, the dynamic linker
    code is contained within the shared C library, which is actually executable
@@ -40,10 +40,9 @@ Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.  */
    executable which correspond to the "startup file", I.E. crt0.o in most
    cases.  This file is assumed to be a startup file and frames with pc's
    inside it are treated as nonexistent.  Setting these variables is necessary
-   so that backtraces do not fly off the bottom of the stack (or top, depending
-   upon your stack orientation).
+   so that backtraces do not fly off the bottom of the stack.
 
-   Gdb also supports an alternate method to avoid running off the top/bottom
+   Gdb also supports an alternate method to avoid running off the bottom
    of the stack.
 
    There are two frames that are "special", the frame for the function
@@ -94,6 +93,8 @@ struct entry_info
 
   CORE_ADDR entry_point;
 
+#define INVALID_ENTRY_POINT (~0) /* ~0 will not be in any file, we hope.  */
+
   /* Start (inclusive) and end (exclusive) of function containing the
      entry point. */
 
@@ -111,8 +112,16 @@ struct entry_info
   CORE_ADDR main_func_lowpc;
   CORE_ADDR main_func_highpc;
 
-};
+/* Use these values when any of the above ranges is invalid.  */
+
+/* We use these values because it guarantees that there is no number that is
+   both >= LOWPC && < HIGHPC.  It is also highly unlikely that 3 is a valid
+   module or function start address (as opposed to 0).  */
+
+#define INVALID_ENTRY_LOWPC (3)
+#define INVALID_ENTRY_HIGHPC (1)
 
+};
 
 /* Sections in an objfile.
 
@@ -140,19 +149,20 @@ struct obj_section {
      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.  */
+  sec_ptr the_bfd_section; /* BFD section pointer */
+
+  /* Objfile this section is part of.  */
   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. */
+/* 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).  */
 
 struct objfile
 {
@@ -198,8 +208,8 @@ struct objfile
 
   struct partial_symtab *free_psymtabs;
 
-  /* The object file's BFD.  Can be null, in which case bfd_open (name) and
-     put the result here.  */
+  /* The object file's BFD.  Can be null if the objfile contains only
+     minimal symbols, e.g. the run time common symbols for SunOS4.  */
 
   bfd *obfd;
 
@@ -226,7 +236,7 @@ struct objfile
      by a "null symbol", one that has a NULL pointer for the name and a zero
      value for the address.  This makes it easy to walk through the array
      when passed a pointer to somewhere in the middle of it.  There is also
-     a count of the number of symbols, which does include the terminating
+     a count of the number of symbols, which does not include the terminating
      null symbol.  The array itself, as well as all the data that it points
      to, should be allocated on the symbol_obstack for this file. */
 
@@ -308,12 +318,15 @@ struct objfile
   struct obj_section
     *sections,
     *sections_end;
+
+  /* two auxiliary fields, used to hold the fp of separate symbol files */
+  FILE *auxf1, *auxf2;
 };
 
 /* Defines for the objfile flag word. */
 
 /* Gdb can arrange to allocate storage for all objects related to a
-   particular objfile in a designated section of it's address space,
+   particular objfile in a designated section of its address space,
    managed at a low level by mmap() and using a special version of
    malloc that handles malloc/free/realloc on top of the mmap() interface.
    This allows the "internal gdb state" for a particular objfile to be
@@ -330,11 +343,24 @@ struct objfile
 
 #define OBJF_SYMS      (1 << 1)        /* Have tried to read symbols */
 
+/* When an object file has its functions reordered (currently Irix-5.2
+   shared libraries exhibit this behaviour), we will need an expensive
+   algorithm to locate a partial symtab or symtab via an address.
+   To avoid this penalty for normal object files, we use this flag,
+   whose setting is determined upon symbol table read in.  */
+
+#define OBJF_REORDERED (2 << 1)        /* Functions are reordered */
+
 /* The object file that the main symbol table was loaded from (e.g. the
    argument to the "symbol-file" or "file" command).  */
 
 extern struct objfile *symfile_objfile;
 
+/* The object file that contains the runtime common minimal symbols
+   for SunOS4. Note that this objfile has no associated BFD.  */
+
+extern struct objfile *rt_common_objfile;
+
 /* When we need to allocate a new type, we need to know which type_obstack
    to allocate the type on, since there is one for each objfile.  The places
    where types are allocated are deeply buried in function call hierarchies
@@ -360,6 +386,11 @@ extern struct objfile *object_files;
 extern struct objfile *
 allocate_objfile PARAMS ((bfd *, int));
 
+extern int
+build_objfile_section_table PARAMS ((struct objfile *));
+
+extern void objfile_to_front PARAMS ((struct objfile *));
+
 extern void
 unlink_objfile PARAMS ((struct objfile *));
 
@@ -398,7 +429,6 @@ find_pc_section PARAMS((CORE_ADDR pc));
        (obj) != NULL? ((nxt)=(obj)->next,1) :0;        \
        (obj) = (nxt))
 
-
 /* Traverse all symtabs in one objfile.  */
 
 #define        ALL_OBJFILE_SYMTABS(objfile, s) \
@@ -414,7 +444,6 @@ find_pc_section PARAMS((CORE_ADDR pc));
 #define        ALL_OBJFILE_MSYMBOLS(objfile, m) \
     for ((m) = (objfile) -> msymbols; SYMBOL_NAME(m) != NULL; (m)++)
 
-
 /* Traverse all symtabs in all objfiles.  */
 
 #define        ALL_SYMTABS(objfile, s) \