This is the mail archive of the mailing list for the libc-ports project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] ARM: Don't apply pointer encryption to the frame pointer

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  <>
> 	* 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]