[Mono-dev] ARM/NativeClient port
olonho at google.com
Tue Feb 5 12:14:25 UTC 2013
Good idea, but unfortunately for [reg + reg] loads it's hard to easily
that address does not escapes sandbox, so NaCL only allows [reg + imm]
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
and patching code decodes location to patch from movw/movt instruction
(similar to what you suggested).
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.
> 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 ().
>> 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.
>>> ARM has PC relative addressing, so it would be easier to use that
>>> instead of reserving a register.
>>> Mono-devel-list mailing list
>>> Mono-devel-list at lists.ximian.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-devel-list