From: Alessandro Carminati <alessandro.carminati@gmail.com>
To: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Daniel Bristot de Oliveira <bristot@kernel.org>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Masahiro Yamada <masahiroy@kernel.org>,
Luis Chamberlain <mcgrof@kernel.org>,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Nicolas Schier <nicolas@fjasle.eu>,
Alexander Lobakin <aleksander.lobakin@intel.com>,
Nick Alcock <nick.alcock@oracle.com>,
Kris Van Hees <kris.van.hees@oracle.com>,
Eugene Loh <eugene.loh@oracle.com>,
Francis Laniel <flaniel@linux.microsoft.com>,
Viktor Malik <vmalik@redhat.com>, Petr Mladek <pmladek@suse.com>,
linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH v4] scripts/link-vmlinux.sh: Add alias to duplicate symbols for kallsyms
Date: Wed, 20 Sep 2023 09:39:41 +0200 [thread overview]
Message-ID: <CAPp5cGS96hcv3GK5n4EdvA9eGf3YnzkCqL01eZPw_RzHMhPoyQ@mail.gmail.com> (raw)
In-Reply-To: <20230920085251.a4e68173ee2539f695182810@kernel.org>
Hello Masami,
Thank you for the feedback.
Il giorno mer 20 set 2023 alle ore 01:52 Masami Hiramatsu
<mhiramat@kernel.org> ha scritto:
>
> On Tue, 19 Sep 2023 19:39:48 +0000
> "Alessandro Carminati (Red Hat)" <alessandro.carminati@gmail.com> wrote:
>
> > It is not uncommon for drivers or modules related to similar peripherals
> > to have symbols with the exact same name.
> > While this is not a problem for the kernel's binary itself, it becomes an
> > issue when attempting to trace or probe specific functions using
> > infrastructure like ftrace or kprobe.
> >
> > The tracing subsystem relies on the `nm -n vmlinux` output, which provides
> > symbol information from the kernel's ELF binary. However, when multiple
> > symbols share the same name, the standard nm output does not differentiate
> > between them. This can lead to confusion and difficulty when trying to
> > probe the intended symbol.
> >
> > ~ # cat /proc/kallsyms | grep " name_show"
> > ffffffff8c4f76d0 t name_show
> > ffffffff8c9cccb0 t name_show
> > ffffffff8cb0ac20 t name_show
> > ffffffff8cc728c0 t name_show
> > ffffffff8ce0efd0 t name_show
> > ffffffff8ce126c0 t name_show
> > ffffffff8ce1dd20 t name_show
> > ffffffff8ce24e70 t name_show
> > ffffffff8d1104c0 t name_show
> > ffffffff8d1fe480 t name_show
> >
> > kas_alias addresses this challenge by enhancing symbol names with
> > meaningful suffixes generated from the source file and line number
> > during the kernel build process.
> > These newly generated aliases provide tracers with the ability to
> > comprehend the symbols they are interacting with when utilizing the
> > ftracefs interface.
> > This approach may also allow for the probing by name of previously
> > inaccessible symbols.
> >
> > ~ # cat /proc/kallsyms | grep gic_mask_irq
> > ffffd15671e505ac t gic_mask_irq
> > ffffd15671e505ac t gic_mask_irq@drivers_irqchip_irq_gic_c_167
> > ffffd15671e532a4 t gic_mask_irq
> > ffffd15671e532a4 t gic_mask_irq@drivers_irqchip_irq_gic_v3_c_407
> > ~ #
> >
> > Changes from v1:
> > - Integrated changes requested by Masami to exclude symbols with prefixes
> > "_cfi" and "_pfx".
> > - Introduced a small framework to handle patterns that need to be excluded
> > from the alias production.
> > - Excluded other symbols using the framework.
> > - Introduced the ability to discriminate between text and data symbols.
> > - Added two new config symbols in this version: CONFIG_KALLSYMS_ALIAS_DATA,
> > which allows data for data, and CONFIG_KALLSYMS_ALIAS_DATA_ALL, which
> > excludes all filters and provides an alias for each duplicated symbol.
> >
> > https://lore.kernel.org/all/20230711151925.1092080-1-alessandro.carminati@gmail.com/
> >
> > Changes from v2:
> > - Alias tags are created by querying DWARF information from the vmlinux.
> > - The filename + line number is normalized and appended to the original
> > name.
> > - The tag begins with '@' to indicate the symbol source.
> > - Not a change, but worth mentioning, since the alias is added to the
> > existing list, the old duplicated name is preserved, and the livepatch
> > way of dealing with duplicates is maintained.
> > - Acknowledging the existence of scenarios where inlined functions
> > declared in header files may result in multiple copies due to compiler
> > behavior, though it is not actionable as it does not pose an operational
> > issue.
> > - Highlighting a single exception where the same name refers to different
> > functions: the case of "compat_binfmt_elf.c," which directly includes
> > "binfmt_elf.c" producing identical function copies in two separate
> > modules.
> >
> > https://lore.kernel.org/all/20230714150326.1152359-1-alessandro.carminati@gmail.com/
> >
> > Changes from v3:
> > - kas_alias was rewritten in Python to create a more concise and
> > maintainable codebase.
> > - The previous automation process used by kas_alias to locate the vmlinux
> > and the addr2line has been replaced with an explicit command-line switch
> > for specifying these requirements.
> > - addr2line has been added into the main Makefile.
> > - A new command-line switch has been introduced, enabling users to extend
> > the alias to global data names.
> >
> > https://lore.kernel.org/all/20230828080423.3539686-1-alessandro.carminati@gmail.com/
> >
> > NOTE:
> > About the symbols name duplication that happens as consequence of the
> > inclusion compat_binfmt_elf.c does, it is evident that this corner is
> > inherently challenging the addr2line approach.
> > Attempting to conceal this limitation would be counterproductive.
> >
> > compat_binfmt_elf.c includes directly binfmt_elf.c, addr2line can't help
> > but report all functions and data declared by that file, coming from
> > binfmt_elf.c.
> >
> > My position is that, rather than producing a more complicated pipeline
> > to handle this corner case, it is better to fix the compat_binfmt_elf.c
> > anomaly.
> >
> > This patch does not deal with the two potentially problematic symbols
> > defined by compat_binfmt_elf.c
>
> Hi, it looks good but if I build with O=<build dir>, I have this error.
>
> /ksrc/linux/scripts/link-vmlinux.sh: 176: scripts/kas_alias.py: not found
>
> Maybe something wrong with setting the path?
You're spot on.
Switching from C to Python for kas_alias has this little quirk where it
doesn't end up in the target script directory anymore. So, if you're using
a specific target build directory, you'll have to hunt down the script in
the source tree. I'll sort this out once I've collected all the feedback.
Regards
Alessandro
next prev parent reply other threads:[~2023-09-20 7:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-19 19:39 [PATCH v4] scripts/link-vmlinux.sh: Add alias to duplicate symbols for kallsyms Alessandro Carminati (Red Hat)
2023-09-19 23:52 ` Masami Hiramatsu
2023-09-20 7:39 ` Alessandro Carminati [this message]
2023-09-20 10:53 ` Francis Laniel
2023-09-20 18:04 ` Alessandro Carminati
2023-09-21 11:48 ` Francis Laniel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPp5cGS96hcv3GK5n4EdvA9eGf3YnzkCqL01eZPw_RzHMhPoyQ@mail.gmail.com \
--to=alessandro.carminati@gmail.com \
--cc=aleksander.lobakin@intel.com \
--cc=bristot@kernel.org \
--cc=eugene.loh@oracle.com \
--cc=flaniel@linux.microsoft.com \
--cc=jpoimboe@kernel.org \
--cc=kris.van.hees@oracle.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=mcgrof@kernel.org \
--cc=mhiramat@kernel.org \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=nick.alcock@oracle.com \
--cc=nicolas@fjasle.eu \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=vmalik@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).