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 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) /
  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

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