2004-05-07 Michael Snyder <msnyder@redhat.com>

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

diff --git a/gdb/symtab.h b/gdb/symtab.h
index c56c05366d37aa3412d30cee2a3b884a8ad37ef8..b30fc89dd75072b37499c8602883bf466563830d 100644 (file)
--- a/gdb/symtab.h
+++ b/gdb/symtab.h
@@ -88,10 +88,10 @@ struct agent_expr;
 struct general_symbol_info
 {
   /* Name of the symbol.  This is a required field.  Storage for the
-     name is allocated on the psymbol_obstack or symbol_obstack for
-     the associated objfile.  For languages like C++ that make a
-     distinction between the mangled name and demangled name, this is
-     the mangled name.  */
+     name is allocated on the objfile_obstack for the associated
+     objfile.  For languages like C++ that make a distinction between
+     the mangled name and demangled name, this is the mangled
+     name.  */
 
   char *name;
 
@@ -311,12 +311,13 @@ struct minimal_symbol
 
   struct general_symbol_info ginfo;
 
-  /* The info field is available for caching machine-specific information
-     so it doesn't have to rederive the info constantly (over a serial line).
-     It is initialized to zero and stays that way until target-dependent code
-     sets it.  Storage for any data pointed to by this field should be allo-
-     cated on the symbol_obstack for the associated objfile.  
-     The type would be "void *" except for reasons of compatibility with older
+  /* The info field is available for caching machine-specific
+     information so it doesn't have to rederive the info constantly
+     (over a serial line).  It is initialized to zero and stays that
+     way until target-dependent code sets it.  Storage for any data
+     pointed to by this field should be allocated on the
+     objfile_obstack for the associated objfile.  The type would be
+     "void *" except for reasons of compatibility with older
      compilers.  This field is optional.
 
      Currently, the AMD 29000 tdep.c uses it to remember things it has decoded
@@ -858,7 +859,7 @@ struct symtab
 
    Even after the source file has been read into a symtab, the
    partial_symtab remains around.  They are allocated on an obstack,
-   psymbol_obstack.  FIXME, this is bad for dynamic linking or VxWorks-
+   objfile_obstack.  FIXME, this is bad for dynamic linking or VxWorks-
    style execution of a bunch of .o's.  */
 
 struct partial_symtab
@@ -1066,9 +1067,6 @@ extern int find_pc_partial_function (CORE_ADDR, char **, CORE_ADDR *,
 
 extern void clear_pc_function_cache (void);
 
-extern int find_pc_sect_partial_function (CORE_ADDR, asection *,
-                                         char **, CORE_ADDR *, CORE_ADDR *);
-
 /* from symtab.c: */
 
 /* lookup partial symbol table by filename */
@@ -1317,6 +1315,8 @@ extern enum language deduce_language_from_filename (char *);
 
 extern int in_prologue (CORE_ADDR pc, CORE_ADDR func_start);
 
+extern CORE_ADDR skip_prologue_using_sal (CORE_ADDR func_addr);
+
 extern struct symbol *fixup_symbol_section (struct symbol *,
                                            struct objfile *);
 
@@ -1362,4 +1362,9 @@ extern struct cleanup *make_cleanup_free_search_symbols (struct symbol_search
 extern void set_main_name (const char *name);
 extern /*const */ char *main_name (void);
 
+/* Global to indicate presence of HP-compiled objects,
+   in particular, SOM executable file with SOM debug info 
+   Defined in symtab.c, used in hppa-tdep.c. */
+extern int deprecated_hp_som_som_object_present;
+
 #endif /* !defined(SYMTAB_H) */