From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) by sourceware.org (Postfix) with ESMTPS id 82177395C85F for ; Wed, 20 May 2020 13:24:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 82177395C85F Received: by mail-lj1-x22a.google.com with SMTP id v16so3670174ljc.8 for ; Wed, 20 May 2020 06:24:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cO1jGc5ULREnsaI/k7CH35zFdZ/OEeunyb7kitlDF/w=; b=cImvl29crk/FwMY1aeE3zpWcmFrvnx4hbPV2k9FIsfk3Sxqk0ct5F/mZYzJkBSPr9E 9eLB4h7cRy4mXyJGnbzUuEZ6R8TtF6n5VyGN5uJTQnMTuNauQwIs98kSBgoMKmmBPQBc KJgIqw4TePIXmJ6j+Y3zoCi03TLC6tKjapDp+L0gjPc2o/GiD/2E2RCcnaYlqPkfNg7U CfHmtrvM/QJWnIESWICFQyh/qfLs0N2ht8gK2tq1yH3CGZGx3rGlMq+pWN68BgkjScVZ blsCNrzxbDE7NoM0Vi2YLavPgCEKEZtuyORhiXt6FveQR/snsUG3611C127X0zjxC/Im 2SBg== X-Gm-Message-State: AOAM532TPBV5AXnxxfFsa+wVGxfjCrhAalapKBmCIsGY4Ey7Eamq3GJz fjnBMHKaGXd7H1i1YM9f7zUu6tXcyMZRryZobZ36ysD6 X-Google-Smtp-Source: ABdhPJywsHMb7qrQkIpvdLtJ6HBagifAY3kWDABpy/pUKvCX4v9mSmIfahjxIAizPN231su3/CYJJocdC4QoktRjK+U= X-Received: by 2002:a05:651c:22d:: with SMTP id z13mr2678371ljn.240.1589981095191; Wed, 20 May 2020 06:24:55 -0700 (PDT) MIME-Version: 1.0 References: <072e4b2b-4d71-b343-c8ef-0edbc6ab6804@simark.ca> <59eeb6ee-1ab2-e5aa-000a-2fb6d522b8d0@simark.ca> In-Reply-To: From: mlimber Date: Wed, 20 May 2020 09:24:43 -0400 Message-ID: Subject: Re: [PATCH] [PR 25678] gdb crashes with "internal-error: sect_index_text not initialized" when .text To: Simon Marchi Cc: gdb-patches@sourceware.org X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, 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 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 13:24:58 -0000 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`. 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.) (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? 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. M