From: Jan Beulich <jbeulich@suse.com>
To: "linux-kbuild@vger.kernel.org" <linux-kbuild@vger.kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>, Nicolas Schier <nsc@kernel.org>
Subject: [PATCH] kallsyms: also special-case symbols aliasing _sinittext
Date: Mon, 7 Sep 2026 08:12:08 +0200 [thread overview]
Message-ID: <58b455fc-814d-4de1-ba2b-262db82b4e28@suse.com> (raw)
In the Xen project, where we use a clone of kallsyms, we encountered the
(rare) situation of trailing symbols immediately ahead of _sinittext
moving between passes 1 and 2 in a way that in just one of the two passes
they would actually alias _sinittext. The same can clearly happen to
Linux.
To consistently discard such symbols on all passes, extend the existing
"corner case" by also considering aliases with _sinittext (_stext really
shouldn't have anything ahead of it). But discard only non-text symbols
there, to avoid discarding true aliases, and assuming that what comes
immediately ahead is (typically r/o) data.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
I'm also a little puzzled by the verification done: The extra linking pass
is engaged if the sizes of the two earlier objects aren't the same. The
sizes, however, can be the same even if there are changes. Later
System.map is also compared against the last pass'es .syms, yet both are
first passed through mksysmap filtering, which removes far more symbols
than kallsyms does. Hence no difference there again doesn't necessarily
mean the symbol table hasn't changed.
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -222,6 +222,11 @@ static int symbol_valid(const struct sym
(s->addr == text_range_inittext->end &&
strcmp(name, text_range_inittext->end_sym)))
return 0;
+ /* Same for non-text aliases of _sinittext. */
+ if (toupper(s->sym[0]) != 'T'
+ && s->addr == text_range_inittext->start
+ && strcmp(name, text_range_inittext->start_sym))
+ return 0;
}
return 1;
reply other threads:[~2026-09-07 6:12 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=58b455fc-814d-4de1-ba2b-262db82b4e28@suse.com \
--to=jbeulich@suse.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=nathan@kernel.org \
--cc=nsc@kernel.org \
/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