From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30545 invoked by alias); 10 Dec 2013 20:05:47 -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 30536 invoked by uid 89); 10 Dec 2013 20:05:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ig0-f172.google.com Received: from Unknown (HELO mail-ig0-f172.google.com) (209.85.213.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 10 Dec 2013 20:05:45 +0000 Received: by mail-ig0-f172.google.com with SMTP id hl1so2745501igb.5 for ; Tue, 10 Dec 2013 12:05:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ougHmCobemNzCDbOfKXYXN4KNh7zB1OME6nPtL8/Zcw=; b=UlbmFEwDhR7+0OInnppWB8USGIu5+C1Y+x36HYTQ7xY/ACUUAFdWS/jFumor5vARj+ VugoUwshcvF8ddRD5Mg8926ay1Nf9y3f8Jt4g1G86mbzfB4IZev895bzsw7kE/0eAnD/ NF17umSBC/Le/kX2kEiIT+zc4lJFmCvg83dERzBH4ILK+oWAPSZjcjKlUrx//aKsLGKX eejfxOr9JYTwWNCHQgv/1rkw6Y5SNjrUjpheEnJg5ESwM7LqilCp/YeGyoVA3iRm3ok3 qrHPj7FaeqK3oFY6XIVm7BC3ADClTVgIXo9ULzAwK/xkagDRbxaGWgOQLcPeHsbj2+Ya JxGw== X-Gm-Message-State: ALoCoQkv0SxqHgdXxBSXX/YXX6ZiXbAEzM8eHycUWToG3/I9CyNKiRK+rLz3NMP/iuM+Epjx1QZ2 MIME-Version: 1.0 X-Received: by 10.42.113.66 with SMTP id b2mr57100506icq.21.1386705938193; Tue, 10 Dec 2013 12:05:38 -0800 (PST) Received: by 10.64.20.52 with HTTP; Tue, 10 Dec 2013 12:05:38 -0800 (PST) In-Reply-To: <52A7641C.7020400@redhat.com> References: <52A74F24.8000805@linaro.org> <52A7641C.7020400@redhat.com> Date: Tue, 10 Dec 2013 20:05:00 -0000 Message-ID: Subject: Re: [PATCH] ARM: Don't apply pointer encryption to the frame pointer From: Will Newton To: "Carlos O'Donell" Cc: "Joseph S. Myers" , "libc-ports@sourceware.org" , Patch Tracking Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg00009.txt.bz2 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. -- Will Newton Toolchain Working Group, Linaro