From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8909 invoked by alias); 11 Feb 2005 16:40:15 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 8875 invoked from network); 11 Feb 2005 16:40:11 -0000 Received: from unknown (HELO sire.mail.pas.earthlink.net) (207.217.120.182) by sourceware.org with SMTP; 11 Feb 2005 16:40:11 -0000 Received: from dialup-94-18-ks1.southwind.net ([216.236.18.94] helo=wichita.edu) by sire.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1Czdpx-0003TR-00 for gdb@sources.redhat.com; Fri, 11 Feb 2005 08:40:09 -0800 Message-ID: <420CDC37.6070705@wichita.edu> Date: Fri, 11 Feb 2005 16:49:00 -0000 From: "Rodney M. Bates" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030428 MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: Design advice, type pointers between object files Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-02/txt/msg00079.txt.bz2 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