Re: [PATCH 2/3] kallsyms: Add APIs to match symbol without .llmv.<hash> suffix.

[Google]

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>