[Mono-dev] ARM/NativeClient port

Nikolay Igotti olonho at google.com
Tue Feb 5 10:26:29 UTC 2013


   Hi Paolo,

On Mon, Feb 4, 2013 at 6:36 PM, Paolo Molaro <lupus at oddwiz.org> wrote:

> >   8. All bl/blx must be bundle-end aligned  and LR is masked before
> return,
> > as everything else in 3.
>
> Can you define precisely what a bundle is in this context? 16 bytes? Does
> it
> need to be aligned? Do the data bundles need alignment, too?
>
Yes, bundle is 16-bytes aligned block of instructions  (or data, in case of
data bundles)
sized 16 bytes. Alignment requirements are of course only for code in
.text, anything in
.data could be arranged the way application wants.


> The use of an extra register makes this unsuitable for the genric ARM
> port, IMHO.
>

Well, it's not mandatory to reserve a register. Instead we can do
movw ip, lo(jumptable)
movw ip, hi(jumptable)
ldr ip, [ip + offset]

It's just code will get a bit bigger. Generally we, at the NaCl team, are
not really fond of arbitrary literals
in the instruction stream (as this is a simple way to use hole in the
sandbox, or inject shellcode externally),
so for us preferable solution would be to move all data including jump
tables to the .data section.


> Can't you combine a data bundle with up to three trampolines which can
> easily access
> the 12 bytes in the data bundle with pc-relative addressing?
>
Yes, that's possible, but still problems with
  - inline constant pools, and thus arbitrary instructions
  - code patching
remains.

 What would you say if instead of using a register we'll use scheme with
initialization of jump table just before use?
It would be 2 additional instructions per trampoline, which is probably not
that bad.

To measure impact we have to implement it and see if it makes any
difference in performance.

 Thanks,
   Nikolay.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20130205/b6e47fec/attachment.html>


More information about the Mono-devel-list mailing list