This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: [PATCH] ARM: Don't apply pointer encryption to the frame pointer
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Will Newton <will dot newton at linaro dot org>, libc-ports at sourceware dot org
- Cc: Patch Tracking <patches at linaro dot org>
- Date: Fri, 13 Dec 2013 10:56:59 -0500
- Subject: Re: [PATCH] ARM: Don't apply pointer encryption to the frame pointer
- Authentication-results: sourceware.org; auth=none
- References: <52A74F24 dot 8000805 at linaro dot org>
On 12/10/2013 12:28 PM, Will Newton wrote:
>
> The frame pointer register is rarely used for that purpose on ARM and
> applications that look at the contents of the jmp_buf may be relying
> on reading the value. Ruby uses the contents of jmp_buf to find the
> root set for garbage collection so relies on this pointer value being
> unencrypted.
>
> ports/ChangeLog.arm:
>
> 2013-12-10 Will Newton <will.newton@linaro.org>
>
> * 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.
This looks good to me.
I agree that because fp might not be used for a frame pointer,
and the AEABI doesn't mandate it, that it might have useful
required information that the ruby GC might need.
So while ruby is wrong in inspecting jmp_buf, we're actually
encrypting a general register which ruby might need to to scan
to correctly support dynamic GC.
As David Miller points out this structure might have been on the
stack and the gc would be scanning the stack looking for valid
pointers and need this information.
Cheers,
Carlos.