* ld-cris/expdyn1.d, ld-cris/expdyn5.d, ld-cris/expdyn6.d,

[deliverable/binutils-gdb.git] / gdb / objfiles.h

diff --git a/gdb/objfiles.h b/gdb/objfiles.h
index 62f239ca9945cab530f766d1fa92ee3ccaf6c7ba..29be97295837695a2330ec7525e40c9dd3b6e9eb 100644 (file)
--- a/gdb/objfiles.h
+++ b/gdb/objfiles.h
@@ -44,9 +44,8 @@ struct objfile_data;
    to the user executable's recorded entry point, as if the call had been made
    directly by the kernel.
 
-   The traditional gdb method of using this info is to use the
-   recorded entry point to set the variables
-   deprecated_entry_file_lowpc and deprecated_entry_file_highpc from
+   The traditional gdb method of using this info was to use the
+   recorded entry point to set the entry-file's lowpc and highpc from
    the debugging information, where these values are the starting
    address (inclusive) and ending address (exclusive) of the
    instruction space in the executable which correspond to the
@@ -57,7 +56,7 @@ struct objfile_data;
 
    NOTE: cagney/2003-09-09: It turns out that this "traditional"
    method doesn't work.  Corinna writes: ``It turns out that the call
-   to deprecated_inside_entry_file destroys a meaningful backtrace
+   to test for "inside entry file" destroys a meaningful backtrace
    under some conditions.  E. g. the backtrace tests in the asm-source
    testcase are broken for some targets.  In this test the functions
    are all implemented as part of one file and the testcase is not
@@ -111,18 +110,6 @@ struct entry_info
 
 #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. */
-
-    CORE_ADDR entry_func_lowpc;
-    CORE_ADDR entry_func_highpc;
-
-    /* Start (inclusive) and end (exclusive) of object file containing the
-       entry point. */
-
-    CORE_ADDR deprecated_entry_file_lowpc;
-    CORE_ADDR deprecated_entry_file_highpc;
-
     /* Start (inclusive) and end (exclusive) of the user code main() function. */
 
     CORE_ADDR main_func_lowpc;
@@ -284,20 +271,8 @@ struct objfile
     /* Obstack to hold objects that should be freed when we load a new symbol
        table from this object file. */
 
-    /* Note ezannoni 2004-02-05: this obstack will become the only
-       obstack per objfile instead of having 3 separate ones with the
-       same lifetime.  I am in the process of gradually migrating the
-       old obstacks to this one, so that it can be used more
-       freely. */
-
     struct obstack objfile_obstack; 
 
-    /* Obstacks to hold objects that should be freed when we load a new symbol
-       table from this object file. */
-
-    struct obstack psymbol_obstack;    /* Partial symbols */
-    struct obstack symbol_obstack;     /* Full symbols */
-
     /* A byte cache where we can stash arbitrary "chunks" of bytes that
        will not change. */
 
@@ -312,7 +287,7 @@ struct objfile
     struct htab *demangled_names_hash;
 
     /* Vectors of all partial symbols read in from file.  The actual data
-       is stored in the psymbol_obstack. */
+       is stored in the objfile_obstack. */
 
     struct psymbol_allocation_list global_psymbols;
     struct psymbol_allocation_list static_psymbols;
@@ -324,7 +299,7 @@ struct objfile
        when passed a pointer to somewhere in the middle of it.  There is also
        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. */
+       to, should be allocated on the objfile_obstack for this file. */
 
     struct minimal_symbol *msymbols;
     int minimal_symbol_count;
@@ -402,7 +377,7 @@ struct objfile
     unsigned num_data;
 
     /* Set of relocation offsets to apply to each section.
-       Currently on the psymbol_obstack (which makes no sense, but I'm
+       Currently on the objfile_obstack (which makes no sense, but I'm
        not sure it's harming anything).
 
        These offsets indicate that all symbols (including partial and
@@ -430,20 +405,21 @@ struct objfile
        SECTIONS points to the first entry in the table, and
        SECTIONS_END points to the first location past the last entry
        in the table.  Currently the table is stored on the
-       psymbol_obstack (which makes no sense, but I'm not sure it's
+       objfile_obstack (which makes no sense, but I'm not sure it's
        harming anything).  */
 
     struct obj_section
      *sections, *sections_end;
 
-    /* two auxiliary fields, used to hold the fp of separate symbol files */
-    FILE *auxf1, *auxf2;
-
     /* Imported symbols */
+    /* FIXME: ezannoni 2004-02-10: This is just SOM (HP) specific (see
+       somread.c). It should not pollute generic objfiles.  */
     ImportEntry *import_list;
     int import_list_size;
 
     /* Exported symbols */
+    /* FIXME: ezannoni 2004-02-10: This is just SOM (HP) specific (see
+       somread.c). It should not pollute generic objfiles.  */
     ExportEntry *export_list;
     int export_list_size;
 
@@ -543,6 +519,10 @@ extern struct objfile *object_files;
 
 extern struct objfile *allocate_objfile (bfd *, int);
 
+extern void init_entry_point_info (struct objfile *);
+
+extern CORE_ADDR entry_point_address (void);
+
 extern int build_objfile_section_table (struct objfile *);
 
 extern void terminate_minimal_symbol_table (struct objfile *objfile);