sandbox/linux/bpf_dsl: remove ErrorCode intermediary representation

sandbox/linux/bpf_dsl: remove ErrorCode intermediary representation

This changes PolicyCompiler to skip the pass that converts ResultExprs
into ErrorCodes, and instead it directly emits instructions using
CodeGen.

Reduces the size of sandbox_linux_unittests in release builds on amd64
by about 30kB.

BUG=414363
Committed: https://crrev.com/1f9ec0e417465d285e5033417a8b9456f3140a68
Cr-Commit-Position: refs/heads/master@{#347470}

[mdempsky, 2015-08-22 01:36:34]

mdempsky@chromium.org changed reviewers:
+ rickyz@chromium.org

[mdempsky, 2015-08-22 01:36:34]

rickyz: Patch #4

[mdempsky, 2015-09-01 02:00:19]

rickyz: FYI, this is the big bpf_dsl cleanup that I've been really looking
forward to for a while. :)

[rickyz (no longer on Chrome), 2015-09-03 23:34:12]

lgtm

Apologies for the super long delay.

https://codereview.chromium.org/1309963002/diff/40001/sandbox/linux/bpf_dsl/p...
File sandbox/linux/bpf_dsl/policy_compiler.cc (right):

https://codereview.chromium.org/1309963002/diff/40001/sandbox/linux/bpf_dsl/p...
sandbox/linux/bpf_dsl/policy_compiler.cc:292: if (sizeof(void*) == 4) {
(Question unrelated to your change): Is there ever likely to be a use case for
compiling policies for a 32-bit process from a 64-bit process (or is the
assumption that the build env is the same as the target env already baked in
elsewhere)? After seeing cross compilation with clang vs. gcc, I've become a fan
of supporting it in one build whenever possible :-)

[mdempsky, 2015-09-04 18:32:09]

Thanks for the review!

https://codereview.chromium.org/1309963002/diff/40001/sandbox/linux/bpf_dsl/p...
File sandbox/linux/bpf_dsl/policy_compiler.cc (right):

https://codereview.chromium.org/1309963002/diff/40001/sandbox/linux/bpf_dsl/p...
sandbox/linux/bpf_dsl/policy_compiler.cc:292: if (sizeof(void*) == 4) {
On 2015/09/03 23:34:11, rickyz wrote:
> (Question unrelated to your change): Is there ever likely to be a use case for
> compiling policies for a 32-bit process from a 64-bit process (or is the
> assumption that the build env is the same as the target env already baked in
> elsewhere)? After seeing cross compilation with clang vs. gcc, I've become a
fan
> of supporting it in one build whenever possible :-)

Agreed that Clang's cross-compiler model is nicer, but at the moment for bpf_dsl
I expect it would require some extra complexity but wouldn't yield any immediate
benefits.

There are a few limitations that make it impractical to compile a policy within
one process and reuse it for a different process (e.g., trap registration is the
major one; but embedding PIDs is another), which limits the value of supporting
cross-compilation for "production" usage.

jln and I have also discussed that it might be nice for unit testing to be able
to more easily verify the 32-bit mode behavior on 64-bit.  However, the limiting
factor there is the bpf_dsl unit tests are still written in a very
integration-testy manner.

So, it's on my mind to remove these host-dependent limitations, just not a high
priority at the moment. :)

[mdempsky, 2015-09-04 18:32:14]

The CQ bit was checked by mdempsky@chromium.org

[commit-bot: I haz the power, 2015-09-04 18:33:31]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1309963002/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1309963002/40001

[commit-bot: I haz the power, 2015-09-04 19:33:01]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2015-09-04 19:34:22]

Patchset 3 (id:??) landed as
https://crrev.com/1f9ec0e417465d285e5033417a8b9456f3140a68
Cr-Commit-Position: refs/heads/master@{#347470}