From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109089 invoked by alias); 17 Feb 2020 16:59:01 -0000 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 Received: (qmail 109080 invoked by uid 89); 17 Feb 2020 16:59:01 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy= X-HELO: gateway24.websitewelcome.com Received: from gateway24.websitewelcome.com (HELO gateway24.websitewelcome.com) (192.185.51.61) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Feb 2020 16:58:59 +0000 Received: from cm14.websitewelcome.com (cm14.websitewelcome.com [100.42.49.7]) by gateway24.websitewelcome.com (Postfix) with ESMTP id C04711993A for ; Mon, 17 Feb 2020 10:58:57 -0600 (CST) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id 3jjVjROOKXVkQ3jjVjoVvN; Mon, 17 Feb 2020 10:58:57 -0600 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=U8YFW061rWBl/6016An7x2MG0hWL6iG1o04exx/iFQM=; b=Pa+2upW+SH0XbNKiiClz9Ts2zn V/6HKYTHba2YrzHMsa2O5O4gcr5VeXbeN+mlpntgNq24ELn8bpMgORsD7NjcaCbGYnB05oWCmDGzT 3PxAQx5DwTMiW/Rer3jKaKIVh; Received: from 75-166-123-50.hlrn.qwest.net ([75.166.123.50]:38490 helo=bapiya) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1j3jjV-004JWC-Ej; Mon, 17 Feb 2020 09:58:57 -0700 From: Tom Tromey To: Luis Machado Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCH 00/14] Share DWARF partial symtabs between objfiles References: <20200215165444.32653-1-tom@tromey.com> <3b7ccfdc-0c9b-4322-d087-1cffa8bf7c4d@linaro.org> Date: Mon, 17 Feb 2020 16:59:00 -0000 In-Reply-To: <3b7ccfdc-0c9b-4322-d087-1cffa8bf7c4d@linaro.org> (Luis Machado's message of "Mon, 17 Feb 2020 09:31:18 -0300") Message-ID: <87k14l9mlr.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2020-02/txt/msg00620.txt.bz2 >>>>> "Luis" == Luis Machado writes: >> "Recently" (a year or two ago) I realized that we could get most of >> the benefits of this split by sharing partial symbol tables. This is >> true because reading partial symbols is the slowest operation that >> users see -- in most cases, expanding a full symtab is reasonably >> quick. Luis> Out of curiosity, what use cases would this cover? I imagine symbol Luis> data could be shared, with a few exceptions, only with binaries that Luis> are equal to the one we've already loaded/we're already debugging. Luis> Is this a common scenario? I think it's uncommon right now, because multi-inferior debugging is uncommon in general. For multi-inferior debugging, I guess it would be more common for this reuse to happen for shared libraries than for executables. For instance, when debugging Firefox, most of the symbols are in one giant shared library, libxul. It is loaded once by the launcher, which then execs and the new inferior loads it again. (This case, I think, still isn't handled -- there's no mechanism for preserving the BFD across an exec yet.) And then, Firefox is now multi-process, and each such process also loads libxul. So here at least, it would be a big improvement. > Would type-sharing also be a common scenario? IMO the ideal would be for all symbols and types to be objfile-independent. The data does not inherently need to be objfile-dependent, it is just an accident of history, where some earlier programmer decided to bake the objfile offsets into symbol addresses. We've made this transformation (to remove the offset from the representation) for minimal and partial symbols, but for full symbols it is just a lot harder to untangle everything. Types, maybe surprisingly, fall into this because types can link to symbols (see cplus_struct_type::template_arguments). Tom