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 B1883395B08C for ; Wed, 20 May 2020 14:12:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B1883395B08C 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.193] (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) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id C8A0B1ED39; Wed, 20 May 2020 10:12:15 -0400 (EDT) Subject: Re: [PATCH] [PR 25678] gdb crashes with "internal-error: sect_index_text not initialized" when .text To: mlimber Cc: gdb-patches@sourceware.org References: <072e4b2b-4d71-b343-c8ef-0edbc6ab6804@simark.ca> <59eeb6ee-1ab2-e5aa-000a-2fb6d522b8d0@simark.ca> From: Simon Marchi Message-ID: Date: Wed, 20 May 2020 10:12:15 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: tl Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.0 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: Wed, 20 May 2020 14:12:18 -0000 On 2020-05-20 9:24 a.m., mlimber wrote: > On Tue, May 19, 2020 at 10:50 AM Simon Marchi > wrote: > > Are we inspecting the same library?  In the libicudata.so.52 you've sent, there > are three load segments: > > $ readelf -l libicudata.so.52.2 | grep LOAD >   LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x166a940 0x166a940 R   0x200000 >   LOAD           0x166af30 0x000000000186af30 0x000000000186af30 0x0000d0 0x0000d0 RW  0x200000 >   LOAD           0x166c000 0x000000000186b000 0x000000000186b000 0x000180 0x000180 RW  0x1000 > > > Ah, my bad. The lib freshly rebuilt from source has two segments, but the one I uploaded has three because I manually set the RPATH on it. (The data lib doesn't really need to be on this since it doesn't have other dependencies, but it just got caught up in a glob of all the ICU libs.) > > So the additional step needed after building from source is to run `patchelf --set-rpath \$ORIGIN libicudata.so.52.2`. Ah that explains the three segments. Good to know, thanks! > To reduce confusion (maybe), I have added two files to the same dropbox folder -- libicudata-unpatched.so.52.2 and libicudata-with-rpath.so.52.2. (I have left the original files I uploaded there for now.) Thanks, it should now be trivial to reproduce with a dummy library knowing what you said above. > (For my own application, I have rebuilt libicu* again after running `./configure --enable-rpath=yes`, and then I get the RPATHs I need so I don't need the patchelf at all. Thus my app's problem is resolved.) >   > > I successfully reproduced the bug using your lib.  Since there's no DWARF > info, it fails in init_entry_point_info.  With my lib, it fails earlier, > when the DWARF info is read.  Anyway, it's all variations of the same bug, > some code assumes that sect_index_text is set to some valid value.< > > > I can now also repro the original bug in a rinky-dink program suitable for unit testing. Can you supply the steps to build a small program to repro the DWARF-related bug? You mean as part of the GDB testsuite? You can check and use this test I've made here: https://sourceware.org/pipermail/gdb-patches/2020-May/168769.html It's not complete, it's missing license headers for example. Once applied in your repo, it can be ran with: $ make check TESTS="gdb.base/solib-no-text.exp" The transcript then be read at gdb/testsuite/gdb.log. > Will both bugs be fixed by a change in one place? That is, is my second patch irrelevant because we'll ultimately fix both bugs at some higher level? If the patch is still valid, I could work to submit an updated patch and test case for my non-DWARF bug now, and then you (or you and I) can work up a test case and fix -- possibly under a new bug ticket -- for the DWARF bug. There are two paths forward I see: (1) make sure sect_index_text is always initialized, even if there's no .text section (2) make GDB aware that sect_index_text could be left to -1 If we chose (1), then the fixes in your patches wouldn't be needed, as sect_index_text will never be -1. If we chose (2), then we should get rid of the code that invents a sect_index_text value when there's no .text section. The fixes in your patches would be needed (or something equivalent), but there would be many other similar fixes needed. I posted this RFC patch that summarizes the problem and starts to implement (2): https://sourceware.org/pipermail/gdb-patches/2020-May/168767.html Simon