From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) by sourceware.org (Postfix) with ESMTPS id A3FAC386F83D for ; Sat, 16 May 2020 20:39:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A3FAC386F83D Received: by mail-lj1-x234.google.com with SMTP id d21so5803679ljg.9 for ; Sat, 16 May 2020 13:39:33 -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=XnLiGDpf1uIHh7Kz/IXHu+JvxGMyUutvbDqcbfWGXKE=; b=M6aRNFkV6KcPDUMM5ogWCyo8QixUID/6Rl6AfZaf4Iw3JiMA+k4Sv+g3Zm9IvK77IE eR41dX2o9duA81/G6yS51+DOMR/LCiLB0QljZ53BcAGdqlbvIYwS0VrdZmwxNG6vbMHg eIdHzCU6vPx3H3Eat3u5Dhc8bl21YoJsGVb5LnfICmJfBIJX2JARlwUg2f7bGBWrhBvO Y3S6HmgmiUvROTsO20Yx8LUXqqGdR5qpub8cUbSt3jj2VPVau4yimHQte0orM2wC7/q/ KrzpBquybws+rZXK0CnsCpWs84h/bNVEhZCXyUhWxP1bNqDdq7qmtCWszrbgy4e2CfIo fzRQ== X-Gm-Message-State: AOAM532BCvnhWMf++jYYsJOJis1cnfTU7inlicoMTGMAC0UUOjDnsMmd jgDCVm2vW2sIQbMovwNlebB393/hhl7gRoQ1jxNysg== X-Google-Smtp-Source: ABdhPJzy4MNsrMCNkUnDYXHGaZKlXDDwkDdfvSfDtw14S4hU2knUP1NVKCNkdv2rAZSuE8Y6OWzAGsdnAqxvU/VdpVQ= X-Received: by 2002:a2e:90da:: with SMTP id o26mr857260ljg.119.1589661572337; Sat, 16 May 2020 13:39:32 -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: Sat, 16 May 2020 16:39:21 -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=-2.5 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: Sat, 16 May 2020 20:39:37 -0000 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. M On Fri, May 15, 2020 at 2:33 PM mlimber wrote: > Hrm. I've tried a number of smaller programs to repro this, including the > steps in the comments using the attachment or building my own, X11, OpenGL, > libicu tests, and also sample Qt apps that link `libicudata.so`. Alas, I > cannot recreate it in small-ish form. > > I've tried various combinations of these on Ubuntu 14.04 x64 building with > gcc 4.9 and also Ubuntu 20.04 x64 with gcc 9.3. > > I can reliably repro it with my full-scale Qt app, but I can't submit > that. When I debug gdb itself, I see where it is going awry in my app -- > with libicudata.so.52, which is a weird data-only library. > > I have updated the patch to be a little cleaner by handling this case > earlier rather than at the end since that the problem is apparently that we > have a non-zero starting address but no text section. Thus, I think it fits > better like: > > --- a/gdb/symfile.c > +++ b/gdb/symfile.c > @@ -829,7 +829,8 @@ struct symfile_segment_data * > ei->entry_point_p = 1; > } > else if (bfd_get_file_flags (objfile->obfd) & DYNAMIC > - && bfd_get_start_address (objfile->obfd) != 0) > + && bfd_get_start_address (objfile->obfd) != 0 > + && objfile->sect_index_text != -1) > { > /* Some shared libraries may have entry points set and be > runnable. There's no clear way to indicate this, so just check > for values other than zero. */ > ei->entry_point = bfd_get_start_address (objfile->obfd); > ei->entry_point_p = 1; > } > else > { > - /* Examination of non-executable.o files. Short-circuit this > stuff. */ > + /* Examination of non-executable.o files or shared library with > + no text segment. Short-circuit this stuff. */ > ei->entry_point_p = 0; > } > > The issue description also says that one needs >2 segments, but I don't > see where that comes in yet. Perhaps that's what I'm missing in trying to > repro it? > > I'm willing to keep trying. Can you recommend any way for me to repro the > issue in a small test case? > > Thanks! > > M > > On Thu, May 14, 2020 at 3:28 PM Simon Marchi wrote: > >> On 2020-05-14 3:12 p.m., mlimber via Gdb-patches wrote: >> > Unfortunately, the simpler repro cases I have tried don't trigger the >> > failure, e.g., >> > >> > // main.c >> > extern int g_global_var; >> > int main() >> > { >> > return g_global_var; >> > } >> > >> > // libglobal.c >> > extern int g_global_var; >> > int g_global_var = 42; >> > >> > I build it like: >> > >> > gcc -shared -nostdlib -fPIC -o libglobal.so libglobal.c >> > gcc -o main main.c -lglobal -L. -Wl,--rpath,\$ORIGIN >> > >> > Running it in GDB works fine. Seems like something more is required. >> > >> > Even following the repro steps listed in the first comment or linking >> > against libicudata.so in a simple program like above work fine for me. >> > >> > My more complicated, real-world use case does consistently repro the bug >> > before the patch but does not after. >> > >> > More digging required. Suggestions welcome! >> > >> > M >> >> If you can make a reproducer that uses Qt, that's a good start. Then we >> can >> track down what's special about this use case, and try to make a >> reproducer >> that doesn't use it. >> >> But for the record, I was able to reproduce the crash using the >> instructions >> in the bug. Keith (comment 3) did too. >> >> Simon >> >