From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5014 invoked by alias); 30 Nov 2012 16:31:25 -0000 Received: (qmail 4934 invoked by uid 22791); 30 Nov 2012 16:31:22 -0000 X-SWARE-Spam-Status: No, hits=-6.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_BJ X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 30 Nov 2012 16:31:13 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qAUGVBV7021304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Nov 2012 11:31:11 -0500 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qAUGV9DB005689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 30 Nov 2012 11:31:10 -0500 From: Tom Tromey To: Yao Qi Cc: Subject: Re: RFC: remove partial_symtab::objfile References: <87fw3t8k01.fsf@fleche.redhat.com> <50B8BBF5.300@codesourcery.com> Date: Fri, 30 Nov 2012 16:31:00 -0000 In-Reply-To: <50B8BBF5.300@codesourcery.com> (Yao Qi's message of "Fri, 30 Nov 2012 22:00:21 +0800") Message-ID: <87boef2gtu.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-11/txt/msg00946.txt.bz2 >>>>> "Yao" == Yao Qi writes: Yao> It is a cleanup to me. What is "symbol table location independence"? Yao> Do we have the description or discussion on it some where? It's come up a few times on the list. The basic idea is that, in most cases, all the data read by the symbol readers is read-only and could be shared between inferiors. This would be desirable for multi-inferior debugging, particularly when the various inferiors all use common shared libraries. The main barrier to having this work is that section offsets are added into the symbol addresses when the symbols are created. So, the idea is to change the readers not to do this, and to change the code to apply the offsets at runtime. Then the symbol data can be moved into struct objfile_per_bfd_storage and automatically shared. One problem for this idea is that dlmopen means that a given file may be mapped more than once in a given inferior. So in this case, things like lookup_minimal_symbol are a problem -- it can't just return a pointer to the unrelocated minimal symbol. I think here we'll need a "bound symbol" that also carries its objfile along with it. So, a pretty big change overall :-( It turns out that it is simplest to do this sharing for partial symbols, since they don't escape the psymtab module. I've worked on this project on and off over the last few years, with a few failures along the way. I've come to view it as a long term thing, mostly out of necessity :( >> @@ -2050,13 +2045,13 @@ xcoff_start_psymtab (struct objfile *objfile, >> are the information for includes and dependencies. */ >> >> static struct partial_symtab * >> -xcoff_end_psymtab (struct partial_symtab *pst, const char **include_list, >> +xcoff_end_psymtab (struct objfile *objfile, >> + struct partial_symtab *pst, const char **include_list, >> int num_includes, int capping_symbol_number, >> struct partial_symtab **dependency_list, >> int number_dependencies, int textlow_not_set) Yao> Why write in this way? to reduce the length of patch? or some other reason? Yeah, just to avoid reformatting. I will rearrange it. Tom