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 6D3573851C0B for ; Mon, 18 May 2020 21:44:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6D3573851C0B 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)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id D5F371ED39; Mon, 18 May 2020 17:44:00 -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: Mon, 18 May 2020 17:44:00 -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.2 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: Mon, 18 May 2020 21:44:11 -0000 On 2020-05-18 5:11 p.m., mlimber wrote: > I built libicudata.so.52.2 from source (no customizations; just needed the particular version my version of Qt was looking for, and I modified the RPATH of the three ICU .so's to look in $ORIGIN for their dependencies since I distribute my app with its dependencies). Note that someone else also reported the libicudata.so being the culprit and that I have not yet triggered the error with the libicudata.so in a smaller program. > > The build steps for the offending .so right out of the build log for the library is: > ``` > gcc -D_REENTRANT  -DU_HAVE_ELF_H=1 -DU_HAVE_ATOMIC=1  -DU_ATTRIBUTE_DEPRECATED= -O2 -std=c99 -Wall -pedantic -Wshadow -Wpointer-arith -Wmissing-prototypes -Wwrite-strings   -c -I../common -I../common -DPIC -fPIC -o ./out/tmp/icudt52l_dat.o ./out/tmp/icudt52l_dat.s > gcc -O2 -std=c99 -Wall -pedantic -Wshadow -Wpointer-arith -Wmissing-prototypes -Wwrite-strings   -static-libstdc++  -shared -Wl,-Bsymbolic -nodefaultlibs -nostdlib -o ../lib/libicudata.so.52.2 ./out/tmp/icudt52l_dat.o -Wl,-soname -Wl,libicudata.so.52  -Wl,-Bsymbolic > ``` > > The assembly file is generated at build-time and is of the form: > ``` > .globl icudt52_dat > .section .note.GNU-stack,"",%progbits > .section .rodata > .balign 16 > .type icudt52_dat,%object > icudt52_dat: > > .long 0x27DA0080,0x14,0x020000,0x446E6D43,1,3,0x706F4320,0x67697279,0x28207468,0x32202943,0x2C333130,0x746E4920,0x616E7265,0x6E6F6974,0x42206C61,0x6E697375,0x20737365,0x6863614D,0x73656E69,0x726F4320,0x61726F70,0x6E6F6974,0x646E6120,0x68746F20,0x2E737265,0x6C6C4120,0x67695220,0x20737468,0x65736552,0x64657672,0x202E,0 > .long 0x0C64,0x6324,0x018370,0x6334,0x01B900,0x6347,0x01B9A0,0x635A,0x01BA00,0x636B,0x01C580,0x637F,0x01C5E0,0x638F,0x01CF90,0x63A2,0x01CFF0,0x63B2,0x020420,0x63C5,0x020480,0x63D5,0x026160,0x63E9,0x0261C0,0x63FC,0x026220,0x640F,0x026280,0x6422,0x0262E0,0x6435 > [snip lots more data] > ``` > I can make the binary of the .so available to you if desired (it is 23 MB). If you can upload it somewhere, it wouldn't hurt. I'm also trying to build icu from the same release. Right now I'm trying to make some sense of the `symfile_find_segment_sections` function here: https://github.com/bminor/binutils-gdb/blob/966dc1a27c55ccb298cb8c7c41c9cc2985cc321a/gdb/symfile.c#L3701 I suspect it's buggy, and "hides" the bug when using some shared libraries (including the one I build myself) which would explain why we see it with some libraries that are missing a .text section and not others. When called for a library that has no .text section, if that library has two segments (which is the case of the library I created), then that function will initialize objfile::sect_index_text to 0 (or some other value that insinuates that there is a .text section). That sounds wrong to me: if the library has no .text section, it would be better to leave sect_index_text to -1, and make sure the rest of the code can cope with that. If I remove `symfile_find_segment_sections` completely, sect_index_text stays -1 for my library and I hit the assertion. I then believe that the correct way forward would be to update the dwarf2/read.c code to deal with a .text section not present. Normally, if there's no .text section, there should be no debug info describing code stuff (only data stuff), so it shouldn't be necessary to use sect_index_text. The library attached to the bug (libtestcase.so) has the particularity of having 3 segments. So `symfile_find_segment_sections` is skipped, sect_index_text stays -1, and we see the assertion. So I'm curious, in your libicudata.so library, how many segments there are. That can be checked with: $ readelf -l libicudata.so.52 | grep LOAD If the libicudata.so.52 is really the problematic one, I'm a bit surprised that you don't always see the problem when debugging a program that uses it. Simon