You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What would it take for bpftrace to be able to use type information from BTF instead of parsing headers? I suppose this support should be added to iovisor/bcc first, and then leverage it from there?
I imagine that a lot of the code in clang_parser would need to be replaced with calls to get the information from btf instead of relying on clang to parse headers for us.
For issues like #329, I think that this would allow for a more reliable struct navigation of the task_struct, and this (should) effectively allow bpftrace to handle structs with #ifdefs on members, where we can otherwise not correctly/reliably calculate field offsets.
Should this issue be filed against bcc instead? Is anyone aware of work going on in this area?
The text was updated successfully, but these errors were encountered:
It looks like BTF has been merged as of 4.18 into the linux kernel https://github.com/iovisor/bcc/blob/master/docs/kernel-versions.md
What would it take for bpftrace to be able to use type information from BTF instead of parsing headers? I suppose this support should be added to iovisor/bcc first, and then leverage it from there?
I imagine that a lot of the code in
clang_parser
would need to be replaced with calls to get the information from btf instead of relying on clang to parse headers for us.For issues like #329, I think that this would allow for a more reliable struct navigation of the
task_struct
, and this (should) effectively allow bpftrace to handle structs with#ifdef
s on members, where we can otherwise not correctly/reliably calculate field offsets.Should this issue be filed against bcc instead? Is anyone aware of work going on in this area?
The text was updated successfully, but these errors were encountered: