* symfile.c (reread_symbols): When re-reading symbols, do all the

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

diff --git a/gdb/symtab.h b/gdb/symtab.h
index 34bc099530a41390aedc2fa00224a87a45e9d80a..b21516894bf7511c76a6bf6658ce81fcc682ffe4 100644 (file)
--- a/gdb/symtab.h
+++ b/gdb/symtab.h
@@ -515,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.  */
 
@@ -551,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;
 
@@ -566,25 +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
-
-/* If we want to do baseregs using this approach we should have a
-   LOC_BASEREG (and LOC_BASEREG_ARG) rather than changing the meaning
-   of LOC_LOCAL, LOC_ARG, etc. based on SYMBOL_BASEREG_VALID.  But
-   this approach provides just a small fraction of the expressiveness
-   of a DWARF location, so it does less than we might want.  On the
-   other hand, it may do more than we need; FRAME_LOCALS_ADDRESS,
-   LOC_REGPARM_ADDR, and similar things seem to handle most of the
-   cases which actually come up.  */
-
-#if 0
-/* This currently fails because some symbols are not being initialized
-   to zero on allocation, and no code is currently setting this value.  */
-#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
@@ -634,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];
 };
 
@@ -994,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));