Replies: 3 comments 3 replies
-
bpftrace has some basic DWARF support; see: https://github.com/bpftrace/bpftrace/blob/master/docs/reference_guide.md#4-uprobeuretprobe-dynamic-tracing-user-level-arguments But it currently does not support local variables. We could, in theory, enhance DWARF support to handle local vars, but it would require some work. To manually work around the limitation, assuming compiler did not optimize them away, you could disassemble your function and figure out when the local var is live in a register and then access the register using |
Beta Was this translation helpful? Give feedback.
-
No, I mean c source file offset, like what systemtap supports.
Yes, I know the ustack must be filtered by current interrupted pid. But I'm just wondering if we can call ustack() in the profile timer probe type.
…---- Replied Message ----
| From | Daniel ***@***.***> |
| Date | 02/24/2024 00:06 |
| To | ***@***.***> |
| Cc | jinhua ***@***.***>***@***.***> |
| Subject | Re: [bpftrace/bpftrace] Does bpftrace support reading the local variable in uprobe? (Discussion #3010) |
I presume you mean to ask if uprobe supports function+offset? In which case yes, bpftrace does support it: https://github.com/bpftrace/bpftrace/blob/master/docs/reference_guide.md#3-uprobeuretprobe-dynamic-tracing-user-level . Along with some additional safety features (so you can't accidentaly clobber the immediate value of insns by placing the probe).
IIUC ustack works when the probe interrupts userspace execution. For uprobe that is the case. For tracepoint it may, depending on if userspace is making a syscall, faulting a page, etc. Profile timer I suspect it would be hit or miss. Depending on what is currently running on CPU at the time.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Is it feasible to add a pid filter for profile timer probe, so that ustack() returns the valid stack which exactly belongs to the process we want?
…---- Replied Message ----
| From | Daniel ***@***.***> |
| Date | 02/24/2024 00:31 |
| To | ***@***.***> |
| Cc | jinhua ***@***.***>***@***.***> |
| Subject | Re: [bpftrace/bpftrace] Does bpftrace support reading the local variable in uprobe? (Discussion #3010) |
Ah, ok. Not yet, but that would be a good feature. We have some basic DWARF support, so infrastructure is there. So adding file offset is definitely a possibility.
You are allowed to call ustack() in profile probe. It just may not always capture a stack:
***@***.***~ $ sudo bpftrace -e 'profile:s:1 { print(ustack) }'
[sudo] password for dxu:
Attaching 1 probe...
0x7fda0374b8e0
0x7fd9e7ff5eb8
0x7fda036d3920
0x841f0f
0x7fda03910d1c
g_main_context_prepare+921
0x7fda4719e491
g_main_loop_run+127
meta_context_run_main_loop+90
0x555dc233dfb7
__libc_start_call_main+122
__libc_start_main+139
0x555dc233e295
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
It seems that bpftrace does not support DWARF, so how to read local variables?
A similar question is does it support file+offset uprobe?
Beta Was this translation helpful? Give feedback.
All reactions