From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2906 invoked by alias); 23 Feb 2020 02:37:10 -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 2894 invoked by uid 89); 23 Feb 2020 02:37:09 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=stone, stepping X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 23 Feb 2020 02:37:08 +0000 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 6F59A1E530; Sat, 22 Feb 2020 21:37:06 -0500 (EST) From: Simon Marchi Subject: Re: [PATCH 00/14] Share DWARF partial symtabs between objfiles To: Tom Tromey , gdb-patches@sourceware.org References: <20200215165444.32653-1-tom@tromey.com> Message-ID: Date: Sun, 23 Feb 2020 02:37:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: <20200215165444.32653-1-tom@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2020-02/txt/msg00902.txt.bz2 On 2020-02-15 11:54 a.m., Tom Tromey wrote: > A long-term goal for multi-inferior debugging has been to "split" an > objfile, so that the bulk of the data can be shared across inferiors. > Although a lot of progress has been made on this front, it has turned > out to be surprisingly difficult to fully implement. > > "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. > > Implementing this also turned out to be tricky; but unlike the > situation with types and symbols, it was possible to do incrementally. > > This series implements this idea for DWARF. It separates > dwarf2_per_objfile into shareable and unshareable parts; then, when > possible, the object is attached to the BFD. > > You can see the difference when timing "add-inferior -exec ./gdb", > after "gdb ./gdb": > > Before: Command execution time: 1.667661 (cpu), 1.687607 (wall) > After : Command execution time: 0.150011 (cpu), 0.151292 (wall) > > In this series I did not rename dwarf2_per_objfile. I'd prefer to do > this after landing this series; it seemed like a large, mostly > cosmetic, and yet hard-to-rebase patch. Also, I wanted to consult > with everyone else about what we ought to call it. > > I also didn't attempt to implement this sharing for CTF. I don't > really know much about CTF; but it seems like it ought to be possible. > (Though I wonder if CTF wouldn't benefit more from simply bypassing > partial symbols entirely.) > > Regression tested on x86-64 Fedora 28. I also did various tests by > hand, and tested it by hand, under valgrind, on a gdb built with > -fdebug-types-section. > > Like I mentioned earlier, this is a tricky series, so it would benefit > from careful review. The main danger is that, if I missed a spot, we > could end up in a situation where gdb will crash in a multi-inferior > scenario. > > Tom I've started to look at this, and this is my initial feeling (as discussed with Tom on IRC). This patch series implements: objfile -> dwarf2 object shared between objfiles -> dwarf2 objfile-specific object With the last pointer getting updated at each entry point of the DWARF code to point to the right "dwarf2 objfile-specific object" according to the context. I think it would be more natural and easier to understand to have : objfile -> dwarf2 objfile-specific object -> dwarf2 object shared between objfiles Many "dwarf2 objfile-specific" objects would point to one "dwarf2 object shared between objfiles", without special tricks. Of course, it's much easier said than done. I'd like to know: did you consider this way of doing it and chose not to do it because of the complexity / size of the change? Is the current patchset a stepping stone towards it? Simon