From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: David Malcolm Newsgroups: gmane.emacs.bugs Subject: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int Date: Mon, 29 Mar 2021 14:11:28 -0400 Message-ID: <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30870"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.38.3 (3.38.3-1.fc33) Cc: andrewjmoreton@gmail.com, 46495@debbugs.gnu.org To: Eli Zaretskii , Andrea Corallo Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Mar 29 20:12:22 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lQwNB-0007t2-3O for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 29 Mar 2021 20:12:21 +0200 Original-Received: from localhost ([::1]:59302 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lQwN9-0001Cx-NG for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 29 Mar 2021 14:12:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48102) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lQwMx-0001Co-9u for bug-gnu-emacs@gnu.org; Mon, 29 Mar 2021 14:12:08 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37990) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lQwMs-0007R8-Fc for bug-gnu-emacs@gnu.org; Mon, 29 Mar 2021 14:12:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lQwMs-00089Z-99 for bug-gnu-emacs@gnu.org; Mon, 29 Mar 2021 14:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: David Malcolm Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 29 Mar 2021 18:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46495 X-GNU-PR-Package: emacs Original-Received: via spool by 46495-submit@debbugs.gnu.org id=B46495.161704150231315 (code B ref 46495); Mon, 29 Mar 2021 18:12:02 +0000 Original-Received: (at 46495) by debbugs.gnu.org; 29 Mar 2021 18:11:42 +0000 Original-Received: from localhost ([127.0.0.1]:49536 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lQwMY-000891-FW for submit@debbugs.gnu.org; Mon, 29 Mar 2021 14:11:42 -0400 Original-Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:43294) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lQwMU-00088s-WE for 46495@debbugs.gnu.org; Mon, 29 Mar 2021 14:11:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1617041498; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pnLlF6HJHRpMwr+XtS3yHKhjHhk0WtaZrZdTd/yIWx4=; b=EVtdQ041nMqVOs1fxGNA/wgeoMpuwBVEwMQ8VR5bKfyku0QZNizCg0l1z67dRLiGJGnaqr v3iMrN6cu4JWQG5Cvj5kboi5AkqY6MAD7bUlpiWlLvNf4d/bfq/6B3MbgloekvIclSK2wS R+Qzi+Fw5IZX/icXGiNGjF4bD8kvI7Y= Original-Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-535-0nXoI3n0P4OYvsMWLhAlHg-1; Mon, 29 Mar 2021 14:11:34 -0400 X-MC-Unique: 0nXoI3n0P4OYvsMWLhAlHg-1 Original-Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5370E802B4F; Mon, 29 Mar 2021 18:11:33 +0000 (UTC) Original-Received: from t14s.localdomain (ovpn-112-18.phx2.redhat.com [10.3.112.18]) by smtp.corp.redhat.com (Postfix) with ESMTP id B95095D9F0; Mon, 29 Mar 2021 18:11:32 +0000 (UTC) In-Reply-To: <83h7ktlwuy.fsf@gnu.org> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmalcolm@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:203264 Archived-At: On Mon, 2021-03-29 at 19:59 +0300, Eli Zaretskii wrote: > > From: Andrea Corallo > > Cc: andrewjmoreton@gmail.com, 46495@debbugs.gnu.org > > Date: Mon, 29 Mar 2021 16:15:56 +0000 > > > > >   > > > https://sourceware.org/pipermail/gdb-patches/2021-March/177334.html > > > > > > Is that possible? > > > > Well if this is what you observe it certainly can be.  There might > > very > > well be something in how/what libgccjit generates that is causing > > this > > difference. > > David, can you please chime in and help us understand what is going > on > here? In theory, libgccjit uses the same code-generation code and the same debuginfo-generation code as a regular gcc invocation. Some ideas: (a) Is libgccjit being invoked multiple times in-process? If so, I wonder if you're running into a latent bug in state-handling in libgccjit that's affecting either code generation or debuginfo generation. Maybe something isn't being reset that should have been? Is there a way to get emacs to only do one libgccjit context compilation per process, and see if that affects things? (b) Alternatively, maybe a simple bug in libgccjit that affects the first in-process invocation? (c) Alternatively, maybe a bug in the emacs jit stuff that's corrupting the stack somehow? Some debugging hooks are here: https://gcc.gnu.org/onlinedocs/jit/topics/contexts.html#debugging > > > are we doing something that could affect the > > > prologue of the natively-compiled Lisp code? > > > > I suspect this is a libgccjit thing, without knowing where the > > difference is coming from it's hard to predict if there's a > > workaround > > we can put in place in the Emacs codebase, but I suspect there's > > not. > > > > If the generated code is correct I think gdb should recognize it > > improving its unwinder, otherwise if this is a libgccjit bug we > > should > > open a PR on bugzilla. In particular, this may be helpful for that: https://gcc.gnu.org/onlinedocs/jit/topics/contexts.html#c.gcc_jit_context_dump_reproducer_to_file > GDB's native platform is ELF-based, so its unwinders' support for > COFF-PE format used by MS-Windows is known to be less thorough. > > > Perhaps if the case is the later one can try a simpler testcase to > > report it using the test we have in the configure or libgccjit > > hello > > world [1].  This might help also analysing how this different frame > > is > > formed. > > I think if David doesn't show us the light, my best bet is to > recompile the Lisp code with debug info and see if that resolves the > problem and/or allows us to understand why the code with no debug > info > produces these effects. I'd try turning on debuginfo generation to see if that helps. Hope this is helpful Dave