[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241226211935.02d34076@batman.local.home>
Date: Thu, 26 Dec 2024 21:19:35 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: LKML <linux-kernel@...r.kernel.org>, Linux Trace Kernel
<linux-trace-kernel@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
linux-kbuild@...r.kernel.org, Masami Hiramatsu <mhiramat@...nel.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Peter Zijlstra
<peterz@...radead.org>, Masahiro Yamada <masahiroy@...nel.org>, Nathan
Chancellor <nathan@...nel.org>, Nicolas Schier <nicolas@...sle.eu>, Zheng
Yejian <zhengyejian1@...wei.com>, Martin Kelly
<martin.kelly@...wdstrike.com>, Christophe Leroy
<christophe.leroy@...roup.eu>, Josh Poimboeuf <jpoimboe@...hat.com>, Mark
Rutland <mark.rutland@....com>
Subject: Re: [POC][RFC][PATCH] build: Make weak functions visible in
kallsyms
On Thu, 26 Dec 2024 15:01:07 -0800
Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> On Thu, 26 Dec 2024 at 13:49, Steven Rostedt <rostedt@...dmis.org> wrote:
> >
> > But then, when the linker removes these functions because they were
> > overridden, the code does not disappear, leaving the pointers in the
> > __mcount_loc locations.
>
> This seems entirely unrelated to weak functions, and will be true for
> any other "linker removed it" (which can happen for other reasons
> too).
>
> So your "fix" seems to be hacking around a symptom.
Yeah, that's why this was just a POC.
>
> And honestly, the kallsyms argument seems bogus too. The problem with
> kallsyms is that it looks up the size the wrong way. Making up new
> function names doesn't fix the problem, it - once again - just hacks
> around the symptom of doing something wrong.
>
> Christ, kallsyms looking at nm output and going by "next symbol" was
> always bogus, but I think that's how the old a.out format worked
> originally.
>
> But "nm" literally takes a "-S" argument. We just don't use it.
>
> So I think the fix is literally to just make kallsysms have the size
> data. Of course, very annoyingly out /proc/kallsyms file format also
> tracks the (legacy) nm output that doesn't have size information.
>
> But I do think that if you hit real problems, you need to fix the
> *source* of the issue, not add another ugly hack around things.
So basically the real solution is to fix kallsyms to know about the end
of functions. Peter Zijlstra mentioned that before, but it would take a
bit more work and understanding of kallsyms to fix it properly.
I'm fine not doing the hack and hopefully one day someone will have the
time to fix kallsyms. This was just something I could do quickly,
knowing it is mostly keeping with the status quo and not actually
fixing the root of the issue. I also needed to refresh my ELF parsing
abilities ;-)
I may take a look at kallsyms internals. I have some spare time before
the new year to try and work on things I don't normally get time to
work on.
-- Steve
Powered by blists - more mailing lists