From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 718 invoked by alias); 10 Dec 2013 20:11:35 -0000 Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org Received: (qmail 705 invoked by uid 89); 10 Dec 2013 20:11:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 10 Dec 2013 20:11:34 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rBAKBM9C014630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Dec 2013 15:11:23 -0500 Received: from [10.3.113.66] (ovpn-113-66.phx2.redhat.com [10.3.113.66]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rBAKBL1g010341; Tue, 10 Dec 2013 15:11:22 -0500 Message-ID: <52A77569.4070705@redhat.com> Date: Tue, 10 Dec 2013 20:11:00 -0000 From: "Carlos O'Donell" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Will Newton CC: "Joseph S. Myers" , "libc-ports@sourceware.org" , Patch Tracking Subject: Re: [PATCH] ARM: Don't apply pointer encryption to the frame pointer References: <52A74F24.8000805@linaro.org> <52A7641C.7020400@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg00010.txt.bz2 On 12/10/2013 03:05 PM, Will Newton wrote: > On 10 December 2013 18:57, Carlos O'Donell wrote: >> On 12/10/2013 01:06 PM, Joseph S. Myers wrote: >>> On Tue, 10 Dec 2013, Will Newton wrote: >>> >>>> 2013-12-10 Will Newton >>>> >>>> * sysdeps/arm/__longjmp.S: Don't apply pointer encryption >>>> to fp register. >>>> * sysdeps/arm/setjmp.S: Likewise. >>>> * sysdeps/arm/include/bits/setjmp.h (JMP_BUF_REGLIST): Add >>>> fp to register list, remove a4. >>>> * sysdeps/unix/sysv/linux/arm/sysdep.h: (PTR_MANGLE_LOAD): >>>> New macro. >>> >>> OK, presuming you've tested this with the glibc testsuite. >>> >> >> Is it really true that ruby checks the FP? >> >> I don't see such code? Can you please point it out? > > In vm_core.h: > > 474 jmp_buf machine_regs; > > In vm.c: > > 1589 if (GET_THREAD() != th && th->machine_stack_start && > th->machine_stack_end) { > 1590 rb_gc_mark_machine_stack(th); > 1591 rb_gc_mark_locations((VALUE *)&th->machine_regs, > 1592 (VALUE *)(&th->machine_regs) + > 1593 sizeof(th->machine_regs) / > sizeof(VALUE)); > 1594 } > > So it looks like a conservative GC that uses the jmp_buf as a data > array to find potentially reachable objects. If fp contained a pointer > to an object then the pointer encryption would render it > undiscoverable and it would not get marked as live and could be > collected in error. > > There are a number of "ifs" involved and I haven't got the testsuite > running yet but it looks like a possibility. > Thanks for pointing that out. I'll get a new glibc to the Fedora ruby maintainer and ask them to test in parallel. Cheers, Carlos.