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

Masami Hiramatsu
2024-08-05T12:53:47Z

On Fri, 2 Aug 2024 17:09:12 +0000
Song Liu <songliubraving@meta.com> wrote:

> Hi Petr,
>
> > On Aug 2, 2024, at 8:45 AM, Petr Mladek <pmladek@suse.com> 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@kernel.org>