[Mono-dev] ARM/NativeClient port
vargaz at gmail.com
Tue Feb 5 06:35:00 UTC 2013
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
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
>> > 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