aboutsummaryrefslogtreecommitdiff
path: root/gdb/symtab.h
diff options
context:
space:
mode:
authorJim Kingdon <jkingdon@engr.sgi.com>1993-09-01 21:15:27 +0000
committerJim Kingdon <jkingdon@engr.sgi.com>1993-09-01 21:15:27 +0000
commitc438b3af2a58c099512730b460c9298149548de6 (patch)
treebc31f63bdeb179b91e5e9f4d1f32e22bc8e418fd /gdb/symtab.h
parentade40d3153e344521d48bddf744bc2b8a1792d06 (diff)
downloadgdb-c438b3af2a58c099512730b460c9298149548de6.zip
gdb-c438b3af2a58c099512730b460c9298149548de6.tar.gz
gdb-c438b3af2a58c099512730b460c9298149548de6.tar.bz2
* symtab.h (struct linetable), xcoffread.c (arrange_linetable):
Revise comments re linetable sorting. * buildsym.c (compare_line_numbers): Sort by pc, not by line. * coffread.c: Tell end_symtab to sort the line table. * coffread.c: Re-work a lot of the coff-specific stuff to use stuff in buildsym.c. This includes coff_finish_block, coff_context_stack, coff_local_symbols, coff_file_symbols, coff_global_symbols, coff_end_symtab and coff_add_symbol_to_list. (read_enum_type): Deal with it now that we have a "struct pending" not a "struct coff_pending". * buildsym.c (end_symtab): Don't realloc subfile->linetable.
Diffstat (limited to 'gdb/symtab.h')
-rw-r--r--gdb/symtab.h24
1 files changed, 14 insertions, 10 deletions
diff --git a/gdb/symtab.h b/gdb/symtab.h
index 8ac6972..5b47bea 100644
--- a/gdb/symtab.h
+++ b/gdb/symtab.h
@@ -523,7 +523,10 @@ enum address_class
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. */
+ 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,
@@ -628,26 +631,27 @@ struct linetable_entry
CORE_ADDR pc;
};
-/* The order of entries in the linetable is significant.
+/* 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).
- 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
+ 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];
};