[Mono-dev] ARM/NativeClient port

[Zoltan Varga]

Hi,

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/dfc36968/attachment.html>