Auto sandboxing: control flow expansions for ARM

Auto sandboxing: branches and call for ARM

Implemented expansions for indirect branch and call.
Added code to cooperate with the legacy pseudo-instruction
expansions in ARMMCNaCl.cpp

R=dschuff@chromium.org

Committed: https://chromium.googlesource.com/native_client/pnacl-llvm/+/8ef7b82709fbe15006418cd63e4d6136d47b3142

[dominickd, 2015-08-05 05:01:48]

Patchset #1 (id:1) has been deleted

[dominickd, 2015-08-05 05:02:03]

Patchset #1 (id:20001) has been deleted

[dominickd, 2015-08-05 05:02:42]

dominickd@google.com changed reviewers:
+ dschuff@chromium.org

[dominickd, 2015-08-05 05:23:36]

Patchset #2 (id:60001) has been deleted

[Derek Schuff, 2015-08-05 06:11:44]

It feels like there must be more tests we can add but I don't have concrete
suggestions right now; i'll look more in the morning.

https://codereview.chromium.org/1269273002/diff/80001/lib/Target/ARM/MCTarget...
File lib/Target/ARM/MCTargetDesc/ARMMCNaClExpander.cpp (right):

https://codereview.chromium.org/1269273002/diff/80001/lib/Target/ARM/MCTarget...
lib/Target/ARM/MCTargetDesc/ARMMCNaClExpander.cpp:85: case
ARM::SFI_NOP_IF_AT_BUNDLE_END:
It looks like this is the logic necessary to keep the auto-sandboxer from
expanding instructions emitted by the old code? Can we get a comment to clarify
that?

edit: i just read the CL description. it explains it, just also add a comment
here.

[Derek Schuff, 2015-08-05 06:12:11]

On 2015/08/05 06:11:44, Derek Schuff wrote:
> It feels like there must be more tests we can add but I don't have concrete
> suggestions right now; i'll look more in the morning.
> 
>
https://codereview.chromium.org/1269273002/diff/80001/lib/Target/ARM/MCTarget...
> File lib/Target/ARM/MCTargetDesc/ARMMCNaClExpander.cpp (right):
> 
>
https://codereview.chromium.org/1269273002/diff/80001/lib/Target/ARM/MCTarget...
> lib/Target/ARM/MCTargetDesc/ARMMCNaClExpander.cpp:85: case
> ARM::SFI_NOP_IF_AT_BUNDLE_END:
> It looks like this is the logic necessary to keep the auto-sandboxer from
> expanding instructions emitted by the old code? Can we get a comment to
clarify
> that?
> 
> edit: i just read the CL description. it explains it, just also add a comment
> here.

what are you doing working right now anyway?

[dominickd, 2015-08-05 06:14:44]

On 2015/08/05 06:12:11, Derek Schuff wrote:
> On 2015/08/05 06:11:44, Derek Schuff wrote:
> > It feels like there must be more tests we can add but I don't have concrete
> > suggestions right now; i'll look more in the morning.
> > 
> >
>
https://codereview.chromium.org/1269273002/diff/80001/lib/Target/ARM/MCTarget...
> > File lib/Target/ARM/MCTargetDesc/ARMMCNaClExpander.cpp (right):
> > 
> >
>
https://codereview.chromium.org/1269273002/diff/80001/lib/Target/ARM/MCTarget...
> > lib/Target/ARM/MCTargetDesc/ARMMCNaClExpander.cpp:85: case
> > ARM::SFI_NOP_IF_AT_BUNDLE_END:
> > It looks like this is the logic necessary to keep the auto-sandboxer from
> > expanding instructions emitted by the old code? Can we get a comment to
> clarify
> > that?
> > 
> > edit: i just read the CL description. it explains it, just also add a
comment
> > here.
> 
> what are you doing working right now anyway?

I want to make sure we can get as far as possible with landing these CLs before
I leave.
I can ask you the same question though :)

[Derek Schuff, 2015-08-05 16:29:03]

On 2015/08/05 06:12:11, Derek Schuff wrote:
> On 2015/08/05 06:11:44, Derek Schuff wrote:
> > It feels like there must be more tests we can add but I don't have concrete
> > suggestions right now; i'll look more in the morning.

I think what I was thinking about were all the crazy ways to do control flow
that aren't branches and calls (e.g. various ways to write to the PC). That can
be a separate CL though. Maybe just change the CL description to say "branches
and calls" rather than the more generic "control flow".

[Derek Schuff, 2015-08-05 22:26:06]

lgtm

[dominickd, 2015-08-05 23:18:10]

Committed patchset #3 (id:100001) manually as
8ef7b82709fbe15006418cd63e4d6136d47b3142 (presubmit successful).