diff options
author | Jim Kingdon <jkingdon@engr.sgi.com> | 1993-09-01 21:15:27 +0000 |
---|---|---|
committer | Jim Kingdon <jkingdon@engr.sgi.com> | 1993-09-01 21:15:27 +0000 |
commit | c438b3af2a58c099512730b460c9298149548de6 (patch) | |
tree | bc31f63bdeb179b91e5e9f4d1f32e22bc8e418fd /gdb/symtab.h | |
parent | ade40d3153e344521d48bddf744bc2b8a1792d06 (diff) | |
download | gdb-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.h | 24 |
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]; }; |