* Design advice, type pointers between object files
@ 2005-02-11 16:49 Rodney M. Bates
2005-02-11 16:50 ` Daniel Jacobowitz
0 siblings, 1 reply; 2+ messages in thread
From: Rodney M. Bates @ 2005-02-11 16:49 UTC (permalink / raw)
To: gdb
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Design advice, type pointers between object files
2005-02-11 16:49 Design advice, type pointers between object files Rodney M. Bates
@ 2005-02-11 16:50 ` Daniel Jacobowitz
0 siblings, 0 replies; 2+ messages in thread
From: Daniel Jacobowitz @ 2005-02-11 16:50 UTC (permalink / raw)
To: Rodney M. Bates; +Cc: gdb
On Fri, Feb 11, 2005 at 10:24:23AM -0600, Rodney M. Bates wrote:
> 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.
There should always be a definition of the type, if there is a variable
which references it. This problem has come up with stabs
cross-references before; caching between objfiles is a bad idea.
There's some code to copy types in gdbtypes.c IIRC.
> 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.
No. These are really bad ideas and they don't scale to the general
case - any of these files could change between runs.
> 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.
Would work, I guess.
The best thing would be to try disabling this and using the type info
from your compiler. If it works, it'll be more efficient.
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2005-02-11 16:49 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-02-11 16:49 Design advice, type pointers between object files Rodney M. Bates
2005-02-11 16:50 ` Daniel Jacobowitz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox