-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Add inline function probing #3095
Conversation
fcef4fa
to
974b393
Compare
I had to change the I still need to check the offset for other archs:
|
Sweet! This is an excellent fix. Haven't had a chance to look at the code yet; hope to look at the base PR today/tomorrow |
9ece794
to
c2ee339
Compare
Clang and GCC don't emit code with the same ABI: Godbolt. Looking at the dwarfdump, Clang's stack args are at the We also discussed about In a later PR, we could ensure correct access to stack arguments by using the location expression emitted for the debugger. |
Yes, Go uses their own calling conventions and ignores System V ABI (on x86). I'm not sure what we can do about it other than detecting that a uprobe is inside a Go program and issuing a warning or disabling the
FYI, kernel fprobes (i.e. our kfunc) now support up to 12 arguments so |
5288112
to
b8e90ce
Compare
Ah, I somehow missed that. In that case, I'm all in for dropping the feature :-) Sorry for the confusion and thanks for clearing it up!
That sounds like a reasonable approach. Maybe we could open an issue to track that. |
a80023e
to
259688b
Compare
Following that, I marked |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm!
tests/runtime/builtin
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it'd be good to leave at least one or two of these in the new form to document/check that stack accesses don't regress?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just thought of one more changelog entry we should include: "Deprecated sarg".
Other than that, looks great and I think it's ready to merge!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd still prefer if we could avoid waiting the entire timeout for the few runtime tests but it's not a hard blocker for me.
LGTM otherwise, nice work!
c202659
to
a3caf64
Compare
PROG config = { probe_inline = 0 } | ||
uprobe:./testprogs/inline_function:square { @count++ } | ||
uretprobe:./testprogs/inline_function:main { exit() } | ||
EXPECT @count: 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess bpftrace initializes this map value to 1 even though it never gets called?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it should be initialized to 0. The test checks that only one (non-inlined) instance of square
is hit (see the inline_function.c
source).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah it's because the last call to square is not inlined. Is that worth a comment in this file as well to clear up possible confusion?
Use the DebugInfo (DWARF) to locate every inlined instances of a uprobe function and attach to all of them. This behaviour is controled by the `probe_inline` config key. Note that using this config disables access to the arguments, because we cannot guarantee inlined function instances follow the System V ABI. Also attach to uprobe functions after their prologue, once the stack frame has been set, which makes collecting stack traces more reliable. This behaviour is the new default for all binaries with DWARF.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Let's go! 🚀 |
Explicitly put numbers into an array on the stack instead of relying on architecture-specific calling conventions for stack-passed parameters. This removes the dependency on the stack pointer's value (which changed as of bpftrace#3095) and makes the tests architecture independent.
Explicitly put numbers into an array on the stack instead of relying on architecture-specific calling conventions for stack-passed parameters. This removes the dependency on the stack pointer's value (which changed as of bpftrace#3095) and makes the tests architecture independent.
Explicitly put numbers into an array on the stack instead of relying on architecture-specific calling conventions for stack-passed parameters. This removes the dependency on the stack pointer's value (which changed as of #3095) and makes the tests architecture independent.
Inserting a probe before the stack frame has been established can lead to issues when collecting the stack.
There might be missing frames. See the runtime test
call.ustack_elf_symtable
wheretest2
is missing.When inserting the probe after the prologue of the function, the stack walker has a better context and won't miss an entry.
Checklist
man/adoc/bpftrace.adoc
CHANGELOG.md