[Mono-dev] ARM/NativeClient port

[Nikolay Igotti]

   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


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