On Fri, 2 Aug 2024 17:09:12 +0000 Song Liu <songliubraving@xxxxxxxx> wrote: > Hi Petr, > > > On Aug 2, 2024, at 8:45 AM, Petr Mladek <pmladek@xxxxxxxx> wrote: > > [...] > > > > > IMHO, it depends on the use case. Let's keep "ping_table/" > > as an example. Why people would want to trace this function? > > There might be various reasons, for example: > > > > 1. ping_table.llvm.15394922576589127018 appeared in a backtrace > > > > 2. ping_table.llvm.15394922576589127018 appeared in a histogram > > > > 3. ping_table looks interesting when reading code sources > > > > 4. ping_table need to be monitored on all systems because > > of security/performance. > > > > The full name "ping_table.llvm.15394922576589127018" is perfectly > > fine in the 1st and 2nd scenario. People knew this name already > > before they start thinking about tracing. > > > > The short name is more practical in 3rd and 4th scenario. Especially, > > when there is only one static symbol with this short name. Otherwise, > > the user would need an extra step to find the full name. > > > > The full name is even more problematic for system monitors. These > > applications might need to probe particular symbols. They might > > have hard times when the symbol is: > > > > <symbol_name_from_sources>.<random_suffix_generated_by_compiler> > > > > They will have to deal with it. But it means that every such tool > > would need an extra (non-trivial) code for this. Every tool would > > try its own approach => a lot of problems. > > > > IMHO, the two APIs could make the life easier. > > > > Well, even kprobe might need two APIs to allow probing by > > full name or without the suffix. > > The problem is, with potential partial inlining by modern compilers, > tracing "symbol name from sources" is not accurate. In our production > kernels, we have to add some explicit "noline" to make sure we can > trace these functions reliably. > > Of course, this issue exists without random suffix: any function > could be partially inlined. However, allowing tracing without the > suffix seems to hint that tracing with "symbol name from sources" > is valid, which is not really true. > > At the moment, I have no objections to keep the _without_suffix > APIs. But for long term, I still think we need to set clear > expectations for the users: tracing symbols from sources is not > reliable. OK, I understand this part. I agree the problem. Even if the symbol is unique on kallsyms (without suffix), it may have a suffix and is not correct function entry. I think to solve this issue, we need a better DWARF, or add a symbol suffix like; https://lkml.org/lkml/2023/12/4/1535 Thank you, > > Thanks, > Song > -- Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>
