[Mono-dev] ARM/NativeClient port

[Nikolay Igotti]

       Hi Zoltan,

 Good idea, but unfortunately for [reg + reg] loads it's hard to easily
verify
that address does not escapes sandbox, so NaCL only allows [reg + imm]
addressing mode.

 So far, my approach is to augment MonoDomain with jumptable field, and
replace inline jumptable with access to this domain-wide table.

 Generated ASM for trampoline looks like:

  movw rX, lo(jump_table_entry_addr)
  movt rX, hi(jump_table_entry_addr)
  ldr rX, [rX]
  bic rX, rX, #MASK ; for NaCL only
  bx rX

and patching code decodes location to patch from movw/movt instruction
(similar to what you suggested).

 Nikolay.

On Tue, Feb 5, 2013 at 10:35 AM, Zoltan Varga <vargaz at gmail.com> wrote:

>
> On Mon, Feb 4, 2013 at 10:34 AM, Nikolay Igotti <olonho at google.com> wrote:
>
>>    Hi Zoltan,
>>
>>  For PC-relative addressing at least 2 conditions has to be satisfied:
>>  1. code must know which PC it runs at
>>  2. offset to data must be smaller than 4K to fit into immediate encoding
>>
>> If we're not using inline constant pools, it would lead to rather tricky
>> memory layout of code
>> interleaved with data.
>>
>>   Nikolay
>>
>>
> PC relative addressing is already used by the runtime in AOT mode, see the
> implementation of the OP_AOTCONST opcode, you can generate:
> movw <temp reg>, 0
> movt <temp reg>, 0
> mov <dreg>, [pc+temp reg]
> and patch the movw/movt when the address of the code and the data is
> known. I.e. for trampolines, this is already known, for methods, you can
> patch the movw/movt
> in mono_arch_patch_code ().
>
>                     Zoltan
>
>
>>
>> On Sun, Feb 3, 2013 at 10:09 PM, Zoltan Varga <vargaz at gmail.com> wrote:
>>
>>> >  Hi,
>>> >
>>> >  We're working on implementation of Mono JIT/ARM for Native Client,
>>> and want to discuss certain details about design of our solution.
>>> >  Native Client's sandboxing mechanism, being a SFI solution, has
>>> rather strict  limitations on how verifiable machine code may look like. To
>>> be precise:
>>>
>>> >  Our idea is to emit per-method (or per class?) "jump table"
>>> somewhere in .data, which contains list of all relocations, and use some
>>> register to point to this table.
>>> > So for example, trampoline like this:
>>> >        ldr ip, [pc, #0]
>>> > b skip
>>> >        .word target
>>> >      skip:
>>> > mov lr, pc
>>> > mov pc, ip
>>> > would become (if r10 is used as jump table base register):
>>> >      .align 4 # for NaCl only
>>> >         ldr ip, [r10, #32] # unique (per-method or class) index for
>>> every callsite
>>> >         nop  # for NaCl only, to have bl at bundle end
>>> >         bic r10, r10, #0xc000000f # for NaCl only
>>> >         bl ip # or blx
>>> >  r10 could point somewhere in method metadata, where its relocation
>>> table is stored.
>>>
>>> > So our question is if someone sees problem with such approach, or
>>> could suggest better alternative. Also advises which register could be used
>>> as the jump table base, and where > to store
>>> > such a table (maybe patch info?) are very welcome.
>>>
>>> Hi,
>>>
>>> ARM has PC relative addressing, so it would be easier to use that
>>> instead of reserving a register.
>>>
>>>                  Zoltan
>>>
>>> _______________________________________________
>>> Mono-devel-list mailing list
>>> Mono-devel-list at lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20130205/845eda37/attachment.html>