This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Design advice, type pointers between object files
- From: "Rodney M. Bates" <rodney dot bates at wichita dot edu>
- To: gdb at sources dot redhat dot com
- Date: Fri, 11 Feb 2005 10:24:23 -0600
- Subject: Design advice, type pointers between object files
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