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

[Will Newton <will.newton@linaro.org>]

On 10 December 2013 18:57, Carlos O'Donell <carlos@redhat.com> 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  <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.
>>
>> 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