4 ms·
Author of BCC here... I hadn't seen shark before, but the mindset does appear similar. A couple comparison points I noticed while briefly investigating shark:
by drzaeus77 11y ago
Author of BCC here... I hadn't seen shark before, but the mindset does appear similar.
A couple comparison points I noticed while briefly investigating shark:
C code is passed to clang+llc as external calls, whereas in BCC clang+llvm are statically linked in.
Both support native (lua/python) bindings to the eBPF maps.
In shark, I don't see that it is easy to dereference kprobe'd function arguments, as it is in `bpf_trace_printk("1 W %s %d %d ?\\n", req->rq_disk->disk_name, ...)` of <bcc>/tools/biosnoop.
This should also answer your last question, which was where is "%s" used. tools/opensnoop also uses string printks.
Comparison points aside, I intentionally made sure that the clang legwork that is being done in BCC is wrapped with a C api, so any language bindings besides python should be trivial to implement. It would be ideal (in my mind) if shark could leverage libbcc and make both tools better in the process.
- fche 11y agoCan you outline how bcc translates that req->rq_disk->disk_name expression to bytecode? AIUI, there are no pointer-dereferencing bytecodes. Is it using the BPF_FUNC_probe_read?
- drzaeus77 11y agoExactly, it is using bpf_probe_read. Internally, BCC uses clang's Rewriter functionality to mangle valid C (but invalid BPF) into valid C with bpf helper functions. The req->rq_disk->disk_name expression would expand into: ({ typeof(char [32]) _val; memset(&_val, 0, sizeof(_val)); bpf_probe_read(&_val, sizeof(_val), (u64)({ typeof(struct gendisk *) _val; memset(&_val, 0, sizeof(_val)); bpf_probe_read(&_val, sizeof(_val), (u64)req + offsetof(struct request, rq_disk)); _val; }) + offsetof(struct gendisk, disk_name)); _val; })); If you are playing with the tools, the BPF() class takes an optional argument debug=, where bit 2 (0x4) will print the rewritten C output for your edification.