Use the verbose parameter to enable the tracer's debugging without recompiling the program

[tsint]

Currently, to enable BPF debugging, you need to recompile the profiler, replace the application on the server, and then replace it back after obtaining useful information. This is very inconvenient, so I thought of directly integrating the BPF program with BPF debugging enabled into the profiler. If BPF debugging needs to be enabled, you only need to restart the application and modify the parameters.

As shown below, you can easily obtain the BPF debug log output.

            etcd-1921    [003] d.h2.  4529.247295: bpf_trace_printk: delta index 6, addrLow 0x3b00, unwindInfo 174

            etcd-1921    [003] d.h2.  4529.247296: bpf_trace_printk: unwind: fp+16

            etcd-1921    [003] d.h2.  4529.247296: bpf_trace_printk: unwind: cfa+-16

            etcd-1921    [003] d.h2.  4529.247297: bpf_trace_printk:  pc: 46b2c5 sp: c00006fff8 fp: 7ffe3eb68f90

            etcd-1921    [003] d.h2.  4529.247297: bpf_trace_printk: ==== Resolve next frame unwinder: frame 5 ====

            etcd-1921    [003] d.h2.  4529.247298: bpf_trace_printk: Text section id for PC 46b2c5 is 178b55ad52677a08 (unwinder 1)

            etcd-1921    [003] d.h2.  4529.247298: bpf_trace_printk: Text section bias is 0, and offset is 46b2c5

            etcd-1921    [003] d.h2.  4529.247298: bpf_trace_printk: ==== unwind_native 5 ====

            etcd-1921    [003] d.h2.  4529.247299: bpf_trace_printk: Pushing 178b55ad52677a08 46b2c5 to position 5 on stack

            etcd-1921    [003] d.h2.  4529.247299: bpf_trace_printk: Look up stack delta for 178b55ad52677a08:46b2c5

            etcd-1921    [003] d.h2.  4529.247300: bpf_trace_printk: Intervals should be from 7 to 219 (mapID 9)

            etcd-1921    [003] d.h2.  4529.247301: bpf_trace_printk: delta index 60, addrLow 0xb2c0, unwindInfo 32769

[athre0z]

Hmm, I had thought about this as well, but I'm not sure whether it's a good idea: the debug blobs are 1MB each, and we'll be updating them frequently. This will probably have rather significant impact on the repository size in the long run. If we want this, we'll probably have to stop committing tracer blobs into git, which in turn means that this repository can no longer be pulled in as a Go module (without an external build system).

[tsint]

Hmm, I had thought about this as well, but I'm not sure whether it's a good idea: the debug blobs are 1MB each, and we'll be updating them frequently. This will probably have rather significant impact on the repository size in the long run. If we want this, we'll probably have to stop committing tracer blobs into git, which in turn means that this repository can no longer be pulled in as a Go module (without an external build system).

What if we put the debug blobs in a separate module and do not commit these debug blobs to git to reduce the impact on the repository size, while keeping the original tracker blobs unchanged? Would this address your concerns?

[athre0z]

Hmm yeah, something along those lines could work. We don't have to go with a separate Go module, though, if that is what you are proposing. It'd probably be enough to go:embed them in a separate file with a _sometag.go suffix that is only compiled in when the person building the profiler explicitly requests it. Other than with the regular tracers, the responsibility to make sure the debug tracers are built somehow before go:embed kicks in would lie with the user. Maybe debugtracers could be a good name for such a tag.

[tsint]

Hmm yeah, something along those lines could work. We don't have to go with a separate Go module, though, if that is what you are proposing. It'd probably be enough to go:embed them in a separate file with a _sometag.go suffix that is only compiled in when the person building the profiler explicitly requests it. Other than with the regular tracers, the responsibility to make sure the debug tracers are built somehow before go:embed kicks in would lie with the user. Maybe debugtracers could be a good name for such a tag.

Your suggestion is a great idea.