Restrict rewrite of unary operators to dereference operator

[pchaigno]

This pull request limits the rewriting of unary operators to the
dereference operator and fixes #344.

Since the whole expression, unary operator included, is replaced by a
call to bpf_probe_read, the dereference operator is currently the
only unary operator properly rewritten anyway. When rewriting an
increment expression (++val) for instance, the increment operator is
lost in translation:

// struct file *val = ++file;
struct file *val = ({ typeof(struct file *) _val;
                      memset(&_val, 0, sizeof(_val));
                      bpf_probe_read(&_val, sizeof(_val), (u64)file);
                      _val; });

Restricting the rewriting to dereference operators fixes #344 because
bcc won't try anymore to translate the logical negation in:
!file->f_op->read_iter.

/cc @drzaeus77 @brendangregg

[pchaigno]

I've added a test case in test_clang.py based on @brendangregg's code in #344.

[4ast]

cc @drzaeus77

[drzaeus77]

I know I played with it once, but can you refresh my memory on whether clang treats (*p). and p-> the same, and whether that would be a problem here?

Also, please rebase since there is now a conflict in test_clang.py.

[pchaigno]

Clang sees p-> as a MemberExpr (taken care of by bcc rewriter in b_frontend_action.cc#L202-L218) whereas it sees *p as a UnaryOperator of opcode UO_Deref (taken care of in b_frontend_action.cc#L219-L256).

So the rewrite isn't equivalent between (*p). and p->:

return !(*file).f_op;
return !file->f_op;

is rewritten into:

return !(({ typeof(struct file) _val;
            memset(&_val, 0, sizeof(_val));
            bpf_probe_read(&_val, sizeof(_val), (u64)file);
            _val; })).f_op;
return !({ typeof(const struct file_operations *) _val;
            memset(&_val, 0, sizeof(_val));
            bpf_probe_read(&_val, sizeof(_val), (u64)file + offsetof(struct file, f_op));
            _val; });

The new test case (!file->f_op->read_iter) serves as a check on the ! more than on the ->s. With this pull request, bcc doesn't try to replace the negation anymore (while the ->s were already correctly replaced).

[drzaeus77]

Ok, please proceed with the rebase.

[drzaeus77]

[buildbot, test this please]