On Mon, 22 Jun 2020 08:27:53 +0800 Ming Lei <ming.lei@xxxxxxxxxx> wrote: > Can you kprobe guys improve the implementation for covering this case? > For example, put probe on 3) in case the above situation is recognized. To do so would require solving the halting problem. https://en.wikipedia.org/wiki/Halting_problem Or perhaps reading the DWARF output of the compiler to determine if it optimized the location you are looking for. The first case is impossible to solve, the second would take a lot of work, (are you going to fund it?) Your comment about tracing internals is valid, but if you can't understand the optimization of the compiler on the kernel, I suggest you stick with the static trace events. kprobes can be added virtual anywhere in the kernel. It's very function requires a kprobe *user* to understand the internals of the kernel as well as its executable binary code, and not expect the kprobe to figure it out for you. We are all for adding infrastructure to make kprobes easier. But figuring out that the kernel optimized a function call so that we can add some wrapper to *simulate* the optimized out function call is something I believe is out of scope for a kprobe. In fact, I would call that a feature! I would like to know that a function was optimized out. When I add a kprobe, I'm more interested in what the compiler actually did to the kernel than what the source code shows us. That is very useful information. -- Steve
