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 CDE5D385DC1F for ; Sat, 16 May 2020 21:05:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org CDE5D385DC1F 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 5563F1EDE5; Sat, 16 May 2020 17:05:43 -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: Sat, 16 May 2020 17:05:42 -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: 7bit X-Spam-Status: No, score=-6.9 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: Sat, 16 May 2020 21:05:45 -0000 On 2020-05-16 4:39 p.m., mlimber wrote: > Thanks, with the comment you left on the issue and the attached libtestcase.so, I can repro it. However, neither of my two patches (which are basically the same anyway) fully fix it because it just bombs out later. More work required, which I'm willing to attempt. > > In the name of building all tests from source, can you advise on how to create an so like libtestcase.so? I've tried to fiddle with options and version scripts to no avail. My objdump looks close but not exact, and my attempts don't repro the error. I was also looking at that right now. The particularity of libtestcase.so is that it has a .debug_info section, so the DWARF debug info reader (dwarf/read.c) kicks in to read the partial symbols (a quick pass to read the debug symbols, to gather just enough things to build some index of what's in it) but there is no .text section. The DWARF-reading code assumes that there is a .text section, hence the failed assertion. For reference, the DWARF in the file is the following: .debug_info contents: 0x00000000: Compile Unit: length = 0x00000032 version = 0x0005 unit_type = DW_UT_compile abbr_offset = 0x0000 addr_size = 0x08 (next unit at 0x00000036) 0x0000000c: DW_TAG_compile_unit DW_AT_name ("scratch.kyuu") DW_AT_use_UTF8 (true) 0x0000001a: DW_TAG_variable DW_AT_name ("foo") DW_AT_external (0x00) DW_AT_type (0x0000002e "s32") DW_AT_location (DW_OP_addr 0x2250) 0x0000002e: DW_TAG_base_type DW_AT_name ("s32") DW_AT_encoding (DW_ATE_signed) DW_AT_byte_size (0x04) 0x00000035: NULL I am not sure how to end up there in a "legitimate" way. Even when I compile a shared library with gcc with just a single global variable, a .text section is created. So perhaps that was created with some particular options, or some other tool In any case, GDB should be fixed, because even with some invalid / crafted input, we shouldn't hit an assertion. It shouldn't be difficult to craft an executable like this I suppose, just compile a standard shared library with debug info and remove .text using objcopy? I don't have time to try that right now. For the test case that will go into gdb's testsuite, it can either be that (remove the section using objcopy) or some manually-crafted DWARF (see other examples in testsuite/gdb.dwarf2). Simon