On 2026/8/18 下午7:56, Petr Pavlu wrote:
On 8/12/26 5:28 AM, Tiezhu Yang wrote:
The helper function is_mapping_symbol() historically checks for both
local labels prefixed with ".L" or "L0" and mapping symbols prefixed
with "$".
...
I think the updated comment and the function name are confusing. They
read as if they are about local symbols in general (STB_LOCAL), but they
should refer only to local label symbols (.L<xyz>, ...). The function
would need to be called is_local_label_or_mapping_symbol() but that is
too long.
If you do want to rename this function, one option is to be consistent
with perf, which implements the same filter and calls it
is_ignored_kernel_symbol().
The comment could also be clearer, for example:
/*
* Ignore local labels (.L*, L0*) and mapping symbols ($*). These symbols are
* not useful for the kernel, for example, they should not appear in kallsyms.
*/
OK, it looks better, will do it in v4.
{
if (str[0] == '.' && str[1] == 'L')
return true;
...
Another comment-only reference to is_mapping_symbol() that should be
updated is in tools/perf/util/symbol.h.
There may be conflicts between modules-next and perf-tools-next:
https://git.kernel.org/pub/scm/linux/kernel/git/modules/linux.git/log/tools/perf/util/symbol.h?h=modules-next
https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/log/tools/perf/util/symbol.h?h=perf-tools-next
So one way is to not modify tools/perf/util/symbol.h if based
on modules-next at this time, the other way is to rebase the
code and then send the series after the merge window.
Please let me know what is the proper way.
Thanks,
Tiezhu
