* Rename remote-es1800.c to remote-es.c
[deliverable/binutils-gdb.git] / gdb / symtab.h
index 82ad9611cf8de15f124d4b2506028b1f38471e0a..c8c311dbfb7aa0f38a5f2a845aa1d6030a6eff26 100644 (file)
@@ -448,10 +448,7 @@ enum address_class
 
   LOC_ARG,
 
-  /* Value address is at SYMBOL_VALUE offset in arglist.  Currently
-     this is used for C++ references (and presumably will be used for
-     Pascal VAR parameters), and is only dereferenced in certain
-     contexts.  */
+  /* Value address is at SYMBOL_VALUE offset in arglist.  */
 
   LOC_REF_ARG,
 
@@ -462,13 +459,21 @@ enum address_class
      FRAME_LOCALS_ADDRESS), and an is_argument flag.
 
      For some symbol formats (stabs, for some compilers at least),
-     gdb generates a LOC_ARG and a LOC_REGISTER rather than a LOC_REGPARM.
-     This is because that's what the compiler does, but perhaps it would
-     be better if the symbol-reading code detected this (is it possible?)
-     and generated a LOC_REGPARM.  */
+     the compiler generates two symbols, an argument and a register.
+     In some cases we combine them to a single LOC_REGPARM in symbol
+     reading, but currently not for all cases (e.g. it's passed on the
+     stack and then loaded into a register).  */
 
   LOC_REGPARM,
 
+  /* Value is in specified register.  Just like LOC_REGPARM except the
+     register holds the address of the argument instead of the argument
+     itself. This is currently used for the passing of structs and unions
+     on sparc and hppa.  It is also used for call by reference where the
+     address is in a register, at least by mipsread.c.  */
+
+  LOC_REGPARM_ADDR,
+
   /* Value is a local variable at SYMBOL_VALUE offset in stack frame.  */
 
   LOC_LOCAL,
@@ -614,6 +619,23 @@ 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.
+
+   A for statement 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;
@@ -1037,8 +1059,10 @@ symbol_file_add PARAMS ((char *, int, CORE_ADDR, int, int, int));
 
 /* source.c */
 
+extern int frame_file_full_name; /* in stack.c */
+
 extern int
-identify_source_line PARAMS ((struct symtab *, int, int));
+identify_source_line PARAMS ((struct symtab *, int, int, CORE_ADDR));
 
 extern void
 print_source_lines PARAMS ((struct symtab *, int, int, int));
This page took 0.023805 seconds and 4 git commands to generate.