On Wed, 2 Oct 2024 15:43:35 +0900 Tatsuya S <[email protected]> wrote:
> > > On 10/1/24 10:47 PM, Steven Rostedt wrote: > > On Tue, 1 Oct 2024 22:27:03 +0900 > > ts <[email protected]> wrote: > > > >>> ... > >>> sh-140 [001] ...1. 18.352601: myevent: > >>> (vfs_write+0x4/0x560) > >>> sh-140 [001] ...1. 18.352602: <stack trace> > >>> => ksys_write > >>> => do_syscall_64 > >>> => entry_SYSCALL_64_after_hwframe > >>> sh-140 [001] ...1. 18.352602: vfs_write > >>> <-ksys_write > >>> sh-140 [001] ...1. 18.352604: <stack trace> > >>> => ftrace_regs_call > >>> => vfs_write > >>> => ksys_write > >>> => do_syscall_64 > >>> => entry_SYSCALL_64_after_hwframe > >>> ------ > >>> As you can see, myevent skips "vfs_write". > >>> (and function tracer still have ftrace_regs_call() ) > >> > >> Thanks for the other tests. This issue may be function_trace_call() > >> specific problem. > >> > >> So I will change the place to increment skip number. > > > > My fear is that we are going to just break it elsewhere. The problem with > > the "skip" is that there's so many configurations when we get here, we may > > not really know what to skip. If the compiler inlines something, then we > > may skip something we do not want to. > > > > I rather have extra information than not enough. > > > > -- Steve > > It may not be clean and be bit redundant, but I think it would be more > maintainable to treat > > "skip(and skipped functions)" separately only at the top(parent) of > functions that display stack trace. I think you'd better make a set of test programs which gets the stacktrace with several different conditions (combinations of tracers/probes/kconfgis) at first. Then we can make sure it does not break anything. Thank you, -- Masami Hiramatsu (Google) <[email protected]>
