* symfile.c (reread_symbols): When re-reading symbols, do all the
[binutils-gdb.git] / gdb / symtab.h
index a9c704a6fee9cb418b28fe5f2bd2ebe50c7be88f..b21516894bf7511c76a6bf6658ce81fcc682ffe4 100644 (file)
@@ -287,7 +287,12 @@ struct minimal_symbol
       mst_text,                        /* Generally executable instructions */
       mst_data,                        /* Generally initialized data */
       mst_bss,                 /* Generally uninitialized data */
-      mst_abs                  /* Generally absolute (nonrelocatable) */
+      mst_abs,                 /* Generally absolute (nonrelocatable) */
+      /* For the mst_file* types, the names are only guaranteed to be unique
+        within a given .o file.  */
+      mst_file_text,           /* Static version of mst_text */
+      mst_file_data,           /* Static version of mst_data */
+      mst_file_bss             /* Static version of mst_bss */
     } type;
 
 };
@@ -510,6 +515,25 @@ enum address_class
 
   LOC_LOCAL_ARG,
 
+  /* Value is at SYMBOL_VALUE offset from the current value of
+     register number SYMBOL_BASEREG.  This exists mainly for the same
+     things that LOC_LOCAL and LOC_ARG do; but we need to do this
+     instead because on 88k DWARF gives us the offset from the
+     frame/stack pointer, rather than the offset from the "canonical
+     frame address" used by COFF, stabs, etc., and we don't know how
+     to convert between these until we start examining prologues.
+
+     Note that LOC_BASEREG is much less general than a DWARF expression.
+     We don't need the generality (at least not yet), and storing a general
+     DWARF expression would presumably take up more space than the existing
+     scheme.  */
+
+  LOC_BASEREG,
+
+  /* Same as LOC_BASEREG but it is an argument.  */
+
+  LOC_BASEREG_ARG,
+
   /* The variable does not actually exist in the program.
      The value is ignored.  */
 
@@ -546,12 +570,8 @@ struct symbol
 
   union
     {
-      /* for OP_BASEREG in DWARF location specs */
-      struct
-       {
-         short regno_valid;    /* 0 == regno invalid; !0 == regno valid */
-         short regno;          /* base register number {0, 1, 2, ...} */
-       } basereg;
+      /* Used by LOC_BASEREG and LOC_BASEREG_ARG.  */
+      short basereg;
     }
   aux_value;
 
@@ -561,19 +581,7 @@ struct symbol
 #define SYMBOL_CLASS(symbol)           (symbol)->class
 #define SYMBOL_TYPE(symbol)            (symbol)->type
 #define SYMBOL_LINE(symbol)            (symbol)->line
-#define SYMBOL_BASEREG(symbol)         (symbol)->aux_value.basereg.regno
-
-/* This currently fails because some symbols are not being initialized
-   to zero on allocation, and no code is currently setting this value.
-   Basereg handling will probably change significantly in the next release.
-   FIXME -fnf */
-
-#if 0
-#define SYMBOL_BASEREG_VALID(symbol) (symbol)->aux_value.basereg.regno_valid
-#else
-#define SYMBOL_BASEREG_VALID(symbol) 0
-#endif
-
+#define SYMBOL_BASEREG(symbol)         (symbol)->aux_value.basereg
 \f
 /* A partial_symbol records the name, namespace, and address class of
    symbols whose types we have not parsed yet.  For functions, it also
@@ -623,26 +631,27 @@ struct linetable_entry
   CORE_ADDR pc;
 };
 
-/* The order of entries in the linetable is significant.
-
-   It should generally be in ascending line number order.  Line table
-   entries for a function at lines 10-40 should come before entries
-   for a function at lines 50-70.
+/* The order of entries in the linetable is significant.  They should
+   be sorted by increasing values of the pc field.  If there is more than
+   one entry for a given pc, then I'm not sure what should happen (and
+   I not sure whether we currently handle it the best way).
 
-   A for statement looks like this
+   Example: a C for statement generally looks like this
 
        10      0x100   - for the init/test part of a for stmt.
        20      0x200
        30      0x300
        10      0x400   - for the increment part of a for stmt.
 
-   FIXME: this description is incomplete.  coffread.c is said to get
-   the linetable order wrong (would arrange_linenos from xcoffread.c
-   work for normal COFF too?).  */
+   */
 
 struct linetable
 {
   int nitems;
+
+  /* Actually NITEMS elements.  If you don't like this use of the
+     `struct hack', you can shove it up your ANSI (seriously, if the
+     committee tells us how to do it, we can probably go along).  */
   struct linetable_entry item[1];
 };
 
@@ -983,6 +992,8 @@ lookup_minimal_symbol PARAMS ((const char *, struct objfile *));
 extern struct minimal_symbol *
 lookup_minimal_symbol_by_pc PARAMS ((CORE_ADDR));
 
+extern struct minimal_symbol *lookup_next_minimal_symbol PARAMS ((CORE_ADDR));
+
 extern void
 init_minimal_symbol_collection PARAMS ((void));
 
@@ -1092,9 +1103,6 @@ extern char **make_symbol_completion_list PARAMS ((char *, char *));
 
 /* symtab.c */
 
-extern void
-clear_symtab_users_once PARAMS ((void));
-
 extern struct partial_symtab *
 find_main_psymtab PARAMS ((void));
 
@@ -1105,6 +1113,9 @@ blockvector_for_pc PARAMS ((CORE_ADDR, int *));
 
 /* symfile.c */
 
+extern void
+clear_symtab_users PARAMS ((void));
+
 extern enum language
 deduce_language_from_filename PARAMS ((char *));