On Mon, Jul 01, 2024 at 03:13:23PM +0200, Petr Mladek wrote:
> So, you suggest to search the symbols by a hash. Do I get it correctly?
>
> Well, it might bring back the original problem. I mean
> the commit 8b8e6b5d3b013b0 ("kallsyms: strip ThinLTO hashes from
> static functions") added cleanup_symbol_name() so that user-space
> tool do not need to take care of the "unstable" suffix.
Are symbol names really considered user ABI?? That's already broken by
design. Even without LTO, the toolchain can mangle them for a variety
of reasons.
If a user space tool doesn't want the suffixes, surely it can figure out
a way to deal with that on their own?
> So, it seems that we have two use cases:
>
> 1. Some user-space tools want to ignore the extra suffix. I guess
> that it is in the case when the suffix is added only because
> the function was optimized.
>
> It can't work if there are two different functions of the same
> name. Otherwise, the user-space tool would not know which one
> they are tracing.
>
>
> 2. There are other use-cases, including livepatching, where we
> want to be 100% sure that we match the right symbol.
>
> They want to match the full names. They even need to distinguish
> symbols with the same name.
>
>
> IMHO, we need a separate API for each use-case.
We should just always link with -zunique-symbols so the duplicate
symbols no longer exist. That would solve a lot of problems.
--
Josh
