Design advice, type pointers between object files

["Rodney M. Bates" <rodney.bates@wichita.edu>]

I'm merging Modula-3 support for gdb, that's been around since
gdb 4.17, into 6.3.  There is an ugly dangling pointer bug that
works like this:

In the symbol for variable, instead of using type info from the
STAB entry, it looks up a symbol for the type by name, using
a name that is encoded inside the variable's mangled name.  When
the symbol is first read, it nulls out the ->type field.  Later,
it does this lookup lazily, on demand, when somebody tries to use the
->type field of the symbol, and caches the result in ->type
for future use. 

The looked-up type symbol can be in a different object file,
and if so, the type and main_type node end up in the objfile_obstack
of the other object file.  If the variable is in the main object
file and the type in a dynamic library, and you do a second
run command, gdb discards and reloads the stuff for the dynamic
libraries but not the main object file, undermining these type
pointers.

I made a quick fix by disabling the caching of the type lookup
process in the ->type field of a symbol, so it gets redone every
time.  This does not necessarily seem like the best overall solution.
It could repeat a lot of work, and the lookup of types can go
a long way recursively, when types are constructed from other
types, many levels deep.

Do any other languages do this, or do they all create copies of
type and main_type nodes in every  objfile-obstack that has symbols
referring to them?  Apparently, somebody believed the STAB type info
produced by the Modula-3 compiler was not good enough, although
it does exist, and I haven't seen any obvious problems with it.

Other possibilities that occur to me:
1. Don't discard dynamic library object files when doing a rerun.
2. Do discard and reload the main object file when doing a rerun.
3. When looking up a type in this way, make copies of the type and
   main_type nodes in the objfile_obstack of the referring symbol. 

1 & 2 would probably call for keeping track, with object-file
granularity, of which objfile_obstacks contained references to
which others, if only to avoid affecting ininvolved languages.
What is the reason for reloading the dynamic libraries?  In
case they have changed?

3 would not create semantic problems, because Modula-3 type
equivalence rules are entirely structural.  If I understand it
right, other languages are making copies of types and main_types
in each objfile_obstack already, when building them from STAB
info for each objfile.  In this case, it might be hard to eliminate
duplicate copies within one objfile_obstack. 

Perhaps someone who is more familiar with the design philosophy
of gdb can shed some light.

-- 
-------------------------------------------------
Rodney M. Bates      rodney.bates@wichita.edu 
Assistant Professor and Graduate Coordinator
Computer Science, Box 83 Wichita State University
1845 Fairmount, Wichita KS 67260-0083 
316-978-3922