From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30507 invoked by alias); 9 Jun 2016 22:01:33 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 30431 invoked by uid 89); 9 Jun 2016 22:01:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=H*M:cygwin, mesa, H*F:U*yselkowitz, staring X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 09 Jun 2016 22:01:29 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B7C29284D8 for ; Thu, 9 Jun 2016 22:01:27 +0000 (UTC) Received: from [10.10.116.38] (ovpn-116-38.rdu2.redhat.com [10.10.116.38]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u59M1QjA011704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Jun 2016 18:01:27 -0400 Subject: Re: [ANNOUNCEMENT] mesa 11.0.9-2 [GOLDSTAR] To: cygwin@cygwin.com References: <570D122B.50307@gmail.com> <570DAFFA.7020700@cygwin.com> <4311402a-fb7d-c68a-9cb3-954161a37e58@dronecode.org.uk> <755f21b3-98aa-9283-0054-369bdb1657a0@dronecode.org.uk> From: Yaakov Selkowitz Message-ID: Date: Thu, 09 Jun 2016 22:01:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <755f21b3-98aa-9283-0054-369bdb1657a0@dronecode.org.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-06/txt/msg00142.txt.bz2 On 6/6/2016 9:27 AM, Jon Turney wrote: > On 06/06/2016 08:24, Yaakov Selkowitz wrote: >> On 2016-06-03 12:56, Jon Turney wrote: >>> On 31/05/2016 18:03, Jon Turney wrote: >>>>> # gdb ./quad-clip >>>>> [...] >>>>> (gdb) r >>>>> [...] >>>>> Program received signal SIGSEGV, Segmentation fault. >>>>> 0x7fdf00c1 in ?? () >>> [...] >>>>> /usr/src/debug/mesa-demos-8.3.0-1/src/trivial/quad-clip.c:137 >>>>> (gdb) disassemble 0x7fdf00b1,0x7fdf00d2 >>>>> Dump of assembler code from 0x7fdf00b1 to 0x7fdf00d2: >>>>> 0x7fdf00b1: insertps $0x10,0x4(%eax,%edi,1),%xmm0 >>>>> 0x7fdf00b9: insertps $0x20,0x8(%eax,%edi,1),%xmm0 >>>>> => 0x7fdf00c1: insertps $0x30,0xfffeff34,%xmm0 >>>>> 0x7fdf00cb: mov (%esi),%eax >>>>> 0x7fdf00cd: mul %ecx >>> >>> After staring this a bit more, I see that this is the offset to the data >>> to load, apparently being used as an absolute address >>> >>> This seems to be the case with other addresses in the JIT-ed code, so >>> perhaps there is some problem preventing relocations being applied... >> >> FWIW, I tried rebuilding with llvm 3.8.0. 32-bit doesn't crash anymore, >> and glxgears says its running, but only the background shows. > > Thanks, that was next on my list to try > > That sounds exactly like what I see with llvm svn r251761 [1] backported > to 3.7.1 (without which we use the x86_64 loader on x86, rather than > reporting an error, due to an interesting use of __builtin_undefined, > with hilarious consequences) > > I guess the output of the JIT code is ending up the wrong place as well, > or something... For the record, Jon seems to have tracked this down, and his fix is in llvm-3.7.1-2. I can only imagine what "fun" he had debugging this, particularly on the address-starved 32-bit platform. Andrew, could you please do the honours? -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple