From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) by sourceware.org (Postfix) with ESMTPS id 0BC553894E49 for ; Tue, 19 May 2020 14:36:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0BC553894E49 Received: by mail-lj1-x22d.google.com with SMTP id u6so13978710ljl.6 for ; Tue, 19 May 2020 07:36:42 -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=j4uen27SuuhVnfoIV2aEfMBJZR1nG9KPIEFuWyZvQd8=; b=HaZxlZNczjr0kAi35Qn8ZzIJoiEP8sVBFvkZYmfe3wDypPD70LYc6GQS7c849+pFtI galg/GdFjCeGmS8V4WX4d43GUHIVDzxeA4MBQimZgkDnMdlNmes7sOUwNCJCVZpQnQEe /48tPVydoQjyWhDf+gE//M28K/rUqor/sRhO5U3GaQIkDCXS4Sx4scn/I/uIcVkyAusL Cw6pw8jdrz82kLue+42iOWW8M0cdX85Nw7+r5XSjncE2zB7Z+Xce7ziB1P7RXr2BiuIc IR8RxwJ/BU+T5uLlSXo9xKEF68wzkezjp2XuKVEqc/r3KoipW1u8YrP6vEysVLoeS8Cg yyhQ== X-Gm-Message-State: AOAM531PNzUv81iEZXZH8JTp9OgLipWYDzHhNlC0NLUExBX1iKex0NNi D29rDDpSwrIzO9A/nP7qUKDcIrRX8vFSeL+adS65ZLUY X-Google-Smtp-Source: ABdhPJySUhvIke1UOHO3GHGeiGP2bzP9pSHnMJIqwto1Efb47DaGNBxlxyHYVHpy7nriCRVcYfKo7ijdVevnJeMS1wQ= X-Received: by 2002:a2e:711c:: with SMTP id m28mr14307070ljc.104.1589899001124; Tue, 19 May 2020 07:36:41 -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: Tue, 19 May 2020 10:36:28 -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.3 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: Tue, 19 May 2020 14:36:46 -0000 On Mon, May 18, 2020 at 5:44 PM Simon Marchi wrote: > If you can upload it somewhere, it wouldn't hurt. I'm also trying to build > icu from the same release. > Here are my ICU libs (built with gcc 4.9 for x64): https://www.dropbox.com/sh/1esshbzshll0hzq/AACBgQgwuSEM_pYQ0HYG_ybXa > 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. > I have skimmed that code, but we're beyond my ken here. The things I observe in that code are: 1. This only acts on files with 1 or 2 segments. (It gets skipped for libtestcase.so as you say.) 2. If the segment info is 1 or 2, it sets two segment indices to refer to this one segment. Perhaps that's legit (I'm a naif when it comes to ELF details), but it struck me as odd. 3. Line 300, where this function is called, has this curious comment: /* This is where things get really weird... We MUST have valid indices for the various sect_index_* members or gdb will abort. So if for example, there is no ".text" section, we have to accomodate that. First, check for a file with the standard one or two segments. */ > 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 > I have two load segments: readelf -l libicudata.so Elf file type is DYN (Shared object file) Entry point 0x2b6 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x000000000166a940 0x000000000166a940 R 200000 LOAD 0x000000000166af30 0x000000000186af30 0x000000000186af30 0x00000000000000d0 0x00000000000000d0 RW 200000 DYNAMIC 0x000000000166af30 0x000000000186af30 0x000000000186af30 0x00000000000000d0 0x00000000000000d0 RW 8 NOTE 0x0000000000000190 0x0000000000000190 0x0000000000000190 0x0000000000000024 0x0000000000000024 R 4 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RW 10 GNU_RELRO 0x000000000166af30 0x000000000186af30 0x000000000186af30 0x00000000000000d0 0x00000000000000d0 R 1 I note that there is an entry point specified on the second line of output, which is curious to me since there is no code in this library. Perhaps if we forced an extra load segment in this .so, it would produce different results due to skipping the function cited above. > 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. > I'm also not sure why it sometimes happens and sometimes doesn't. Could it be something with how or when it is loaded -- say, in a certain sequence or via a manual dlopen() instead of via dynamic linking info? M