Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

trace, argdist: STRCMP helper function #772

Merged
merged 3 commits into from
Oct 20, 2016
Merged

Conversation

goldshtn
Copy link
Collaborator

Hacky solution, but works: STRCMP is replaced by a static inline function call that compares a runtime string to a compile-time literal constant. This is good enough to unroll so we don't need a backward jump, which is forbidden by BPF. Quite useful examples can arise, such as tracing opens to a specific file, aggregating operations on a specific device, and so on.

/cc @brendangregg

`trace` filters and print expressions can now use the
magic STRCMP helper function to compare strings. The first
string must be a compile-time constant literal string,
such as "test", and the second string can be determined at
runtime (e.g., from a function argument). The codegen for
STRCMP is on a case-by-case basis for each literal string,
and it generates an inline function with a constant-length
loop that compares the string's characters. This is a
decent workaround until we get something more reasonable
from the kernel side, such as a `bpf_strcmp` helper.

Usage example:

```
trace 'p:c:open (STRCMP("test.txt", arg1)) "%s", arg1'
``
argdist filter expressions can now use the STRCMP helper
function to compare strings. The first string must be a
compile-time constant literal string, and the second string
can be determined at runtime. This is a workaround until
BPF introduces a kernel builtin for strcmp.

Example:

```
argdist -H 'r:c:open(char *file):u64:$latency:STRCMP("test.txt",file)'
```
@brendangregg
Copy link
Member

Neat workaround. I'd be inclined to put a comment above it to say "# this is a workaround implementation of strcmp(). In the future this might get replaced. See #691."

We can see how painful there workarounds are in practice. They make be good enough...

@brendangregg
Copy link
Member

I'm happy to merge; I don't know if @4ast / @drzaeus77 wanted to comment, or at least know we're trying out this workaround. :)

@4ast
Copy link
Member

4ast commented Oct 20, 2016

lgtm

@brendangregg brendangregg merged commit 315998d into iovisor:master Oct 20, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants