From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 081D2385B835 for ; Sun, 29 Mar 2020 15:39:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 081D2385B835 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca 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 72B871E5F9; Sun, 29 Mar 2020 11:39:32 -0400 (EDT) From: Simon Marchi Subject: Re: [PATCH][gdb] Fix missing symtab includes To: Tom de Vries , gdb-patches@sourceware.org Cc: Tom Tromey References: <20200327204948.GA23365@delia> <44300932-0e15-c3b6-9ce8-44e08dd5d8ef@suse.de> Message-ID: Date: Sun, 29 Mar 2020 11:39:31 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <44300932-0e15-c3b6-9ce8-44e08dd5d8ef@suse.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US-large Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-13.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2020 15:39:35 -0000 On 2020-03-28 1:24 p.m., Tom de Vries wrote: >> I am not able to reproduce this. In both cases, I don't get the `includes`. >> >> What transformation is dwz expected to do on the binary? Here, it looks like >> it just compressed the debug info a little bit, changing the addresses, but the >> general structure was untouched. >> >> I'm using the latest git version of dwz (commit b7111689a2ccec2f57343f1051ec8f1df5e89e5c). > > Hi Simon, > > thanks for trying this out. > > I've attached the original a.out here ( > https://sourceware.org/bugzilla/show_bug.cgi?id=25718#c3 ) and the > dwz-ed a.out here ( > https://sourceware.org/bugzilla/show_bug.cgi?id=25718#c4 ). > > I'm hoping you might be able to reproduce using the latter file (and > FWIW, I'm using the same dwz version). > > I think the reason for the difference in what we are seeing is due to me > using openSUSE, which has debug info on various linked in objects like > glibc's init.c and elf-init.c. Looking at the readelf -wi output of the > dwz-ed executable, dwz exploits commonality between those objects and > hello.c, so it's not surprising dwz does not create partial units for > platforms that do not have debug info for those objects. > > Anyway, I'll need to construct a better test-case that reproduces the > problem on other platforms. > > Thanks, > - Tom > Thanks, your explanations make more sense with the the DWARF in those files, I can reproduce the problem now. I have a bit of trouble understanding the current code. In particular, I am trying to put in words what's the difference between the `read_symtab` and `expand_symtab` methods of `partial_symtab`, but I can't quite do it. I think this would help to determine what's the right solution. Simon