<div>       Hi Zoltan,</div><div><br></div> Good idea, but unfortunately for [reg + reg] loads it's hard to easily verify<div>that address does not escapes sandbox, so NaCL only allows [reg + imm] </div><div>addressing mode. </div>
<div><br></div><div> So far, my approach is to augment MonoDomain with jumptable field, and</div><div>replace inline jumptable with access to this domain-wide table. </div><div> </div><div> Generated ASM for trampoline looks like:</div>
<div><br></div><div>  movw rX, lo(jump_table_entry_addr)</div><div>  movt rX, hi(jump_table_entry_addr)</div><div>  ldr rX, [rX]</div><div>  bic rX, rX, #MASK ; for NaCL only</div><div>  bx rX</div><div><br></div><div>and patching code decodes location to patch from movw/movt instruction (similar to what you suggested).</div>
<div><br></div><div> Nikolay.<br><br><div class="gmail_quote">On Tue, Feb 5, 2013 at 10:35 AM, Zoltan Varga <span dir="ltr"><<a href="mailto:vargaz@gmail.com" target="_blank">vargaz@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><div class="gmail_quote"><div class="im">On Mon, Feb 4, 2013 at 10:34 AM, Nikolay Igotti <span dir="ltr"><<a href="mailto:olonho@google.com" target="_blank">olonho@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div>   Hi Zoltan,</div><div><br></div> For PC-relative addressing at least 2 conditions has to be satisfied:<div> 1. code must know which PC it runs at</div><div> 2. offset to data must be smaller than 4K to fit into immediate encoding</div>


<div><br></div><div>If we're not using inline constant pools, it would lead to rather tricky memory layout of code </div><div>interleaved with data.</div><div><br></div><div>  Nikolay</div>
</div><div class="gmail_extra"><br></div></blockquote><div><br></div></div><div>PC relative addressing is already used by the runtime in AOT mode, see the implementation of the OP_AOTCONST opcode, you can generate:</div>
<div>movw <temp reg>, 0</div>
<div>movt <temp reg>, 0</div><div>mov <dreg>, [pc+temp reg]</div><div>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</div>

<div>in mono_arch_patch_code ().</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>                    Zoltan</div></font></span><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_extra">
<br><div class="gmail_quote"><div><div>On Sun, Feb 3, 2013 at 10:09 PM, Zoltan Varga <span dir="ltr"><<a href="mailto:vargaz@gmail.com" target="_blank">vargaz@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div style="font-size:13px;font-family:arial,sans-serif"><div><div style="font-size:13px">
>  Hi,</div><div style="font-size:13px">
></div><div style="font-size:13px">>  We're working on implementation of Mono JIT/ARM for Native Client, and want to discuss certain details about design of our solution.</div>
<div style="font-size:13px">>  Native Client's sandboxing mechanism, being a SFI solution, has rather strict  limitations on how verifiable machine code may look like. To be precise:</div><div style="font-size:13px">



<br></div></div><div><div style="font-size:13px"><div class="gmail_default">>  O<span style="font-size:13px">ur 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.</span></div>



</div><div style="font-size:13px">> So for example, trampoline like this:</div><div style="font-size:13px"><div>>        ldr ip, [pc, #0]</div><div><span style="white-space:pre-wrap">>     </span>b skip</div><div>>        .word target</div>



<div>>      skip:</div><div><span style="white-space:pre-wrap">>     </span>mov lr, pc</div><div><span style="white-space:pre-wrap">>   </span>mov pc, ip</div><div>> would become (if r10 is used as jump table base register):</div>



<div>>      .align 4 # for NaCl only</div><div>>         ldr ip, [r10, #32] # unique (per-method or class) index for every callsite</div><div>>         nop  # for NaCl only, to have bl at bundle end</div><div>>         bic r10, r10, #0xc000000f # for NaCl only</div>



<div>>         bl ip # or blx<br></div></div><div style="font-size:13px">>  r10 could point somewhere in method metadata, where its relocation table is stored.</div><div style="font-size:13px"><br></div><div style="font-size:13px">



> 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</div><div style="font-size:13px">



> such a table (maybe patch info?) are very welcome.</div><div style="font-size:13px"><br></div></div><div style="font-size:13px">Hi,</div><div style="font-size:13px"><br></div><div style="font-size:13px">ARM has PC relative addressing, so it would be easier to use that instead of reserving a register.</div>


<span><font color="#888888">
<div style="font-size:13px"><br></div><div style="font-size:13px">                 Zoltan</div></font></span></div>
<br></div></div>_______________________________________________<br>
Mono-devel-list mailing list<br>
<a href="mailto:Mono-devel-list@lists.ximian.com" target="_blank">Mono-devel-list@lists.ximian.com</a><br>
<a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list" target="_blank">http://lists.ximian.com/mailman/listinfo/mono-devel-list</a><br>
<br></blockquote></div><br></div>
</blockquote></div></div></div><br>
</blockquote></div><br></div>