From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10309 invoked by alias); 22 Jan 2015 20:36:58 -0000 Mailing-List: contact jit-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: Sender: jit-owner@gcc.gnu.org Received: (qmail 10276 invoked by uid 89); 22 Jan 2015 20:36:56 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com X-Authentication-Warning: tucnak.zalov.cz: jakub set sender to jakub@redhat.com using -f Date: Thu, 01 Jan 2015 00:00:00 -0000 From: Jakub Jelinek To: David Malcolm Cc: jit@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: [PATCH] PR 64722: fix corruption of %ebx on 32-bit i386 with libgccjit Message-ID: <20150122203650.GK1746@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <1421948077-57574-1-git-send-email-dmalcolm@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1421948077-57574-1-git-send-email-dmalcolm@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-SW-Source: 2015-q1/txt/msg00034.txt.bz2 On Thu, Jan 22, 2015 at 12:34:37PM -0500, David Malcolm wrote: > Much of the jit testsuite currently segfaults on i686, after > two in-process iterations. In odd-numbered iterations, > gcc_jit_context_compile generates correct code, but on > even-numbered iterations, the generated code trashes the > %ebx register, leading to SIGSEGV back at the call site when > setting up iteration 3. > > The root cause is due to missing state cleanup when repeatedly > invoking the compiler in-process. > > The issue manifests in emit-rtl.c:init_emit_regs, at > this initialization: > > if ((unsigned) PIC_OFFSET_TABLE_REGNUM != INVALID_REGNUM) > pic_offset_table_rtx = gen_raw_REG (Pmode, PIC_OFFSET_TABLE_REGNUM); > else > pic_offset_table_rtx = NULL_RTX; > > On 32-bit i386 fPIC the definition PIC_OFFSET_TABLE_REGNUM itself > depends on pic_offset_table_rtx, and hence the above initialization > code cycles between switching pic_offset_table_rtx from NULL to > non-NULL (on odd-numbered iterations), then switching it back from > non-NULL to NULL (on even-numbered iterations). In the latter case, > this leads to generated code that's supposedly "fPIC", but erroneously > doesn't bother saving %ebx. > > The simple fix is to set pic_offset_table_rtx to NULL_RTX before > testing PIC_OFFSET_TABLE_REGNUM (and thus making the else clause > redundant). A more involved fix might be for the JIT to only > initialize RTL once, but doing so seems higher risk. > > Tested with "make check-jit" on i686; with this, all testcases pass > (with the usual 5 in-process iterations). > > Bootstrap®rtest in progress. > > OK for trunk if it passes? > > gcc/ChangeLog: > PR 64722 Please use PR jit/64722 > * emit-rtl.c (init_emit_regs): Set pic_offset_table_rtx to > NULL_RTX before testing PIC_OFFSET_TABLE_REGNUM, since the > latter may be affected by the former (e.g. on i686). Just wanted to note that I've bootstrapped/regtested the same patch successfully on x86_64-linux and i686-linux. Jakub