[PATCH 0/2] kbuild: link-vmlinux.sh: more reliable 3rd pass linking

[PATCH 0/2] kbuild: link-vmlinux.sh: more reliable 3rd pass linking

[André Draszik]

link-vmlinux.sh currently only uses the file size of
.tmp_vmlinux?.kallsyms.o to determine if it needs to do a third pass. I
was hitting a case where file size didn't change, but symbols changed
sufficiently to still move subsequent symbols in vmlinux to invalidate
kallsyms.

In particular kallsyms_names grew by one byte between
.tmp_vmlinux1.kallsyms.o and .tmp_vmlinux2.kallsyms.o, moving the next
symbol to the next alignment offset (4 bytes), moving many subsequent
symbols in the final vmlinux image in turn (until abosrbed by further
alignment instructions). This failed the final link with:

    Inconsistent kallsyms data
    Try "make KALLSYMS_EXTRA_PASS=1" as a workaround

The two patches here are independent of each other:
* Patch 2 in this series addresses the actual issue and also has a more
  detailed explanation with exact failure case
* Patch 1 could be omitted if deemed useless, but I found it useful
  while debugging the issue. It just updates the kallsyms.c to instruct
  the assembler to also emit symbol sizes.

Cheers,
Andre'

Signed-off-by: André Draszik <andre.draszik@linaro.org>
---
André Draszik (2):
      kallsyms: add symbol size for kallsyms symbols that can change size
      kbuild: link-vmlinux.sh: improve detection of third pass requirement

 scripts/kallsyms.c      |  4 ++++
 scripts/link-vmlinux.sh | 20 +++++++++++++++++++-
 2 files changed, 23 insertions(+), 1 deletion(-)
---
base-commit: 0d33d21e47d9dc66f91e44da3fc9220c74d93df7
change-id: 20260728-linux-kallsyms-fix-95eff49b75b3

Best regards,
-- 
André Draszik <andre.draszik@linaro.org>

[PATCH 1/2] kallsyms: add symbol size for kallsyms symbols that can change size

[André Draszik]

Add symbol size for kallsyms symbols that can change size so that sizes
can be determined easily without having to manually calculate them
when inspecting the object files (.tmp_vmlinux?.kallsyms.o or
.tmp_vmlinux?). Without, the assembler records the symbol size as 0.

This is primarily useful as a debugging aid in case of linker errors as
part of link-vmlinux.sh, and because symbol size doesn't have to align
with the offset to the next symbol due to padding/alignment.

Signed-off-by: André Draszik <andre.draszik@linaro.org>

---
I've opted to only add this for symbols that can change between runs
where relevant, in particular kallsyms_num_syms and
kallsyms_token_index have a static size. While kallsyms_seqs_of_names
depends on table_cnt, kallsyms_offsets does so as well, i.e. is covered
already.

If you think for consistency just to do this for all symbols, please
let me know.
---
 scripts/kallsyms.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index 37d5c095ad22..494852ade6d8 100644
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -398,11 +398,13 @@ static void write_src(void)
 		strcpy((char *)table[i]->sym, buf);
 		printf("\t/* %s */\n", table[i]->sym);
 	}
+	printf(".size kallsyms_names, . - kallsyms_names\n");
 	printf("\n");
 
 	output_label("kallsyms_markers");
 	for (i = 0; i < markers_cnt; i++)
 		printf("\t.long\t%u\n", markers[i]);
+	printf(".size kallsyms_markers, . - kallsyms_markers\n");
 	printf("\n");
 
 	free(markers);
@@ -415,6 +417,7 @@ static void write_src(void)
 		printf("\t.asciz\t\"%s\"\n", buf);
 		off += strlen(buf) + 1;
 	}
+	printf(".size kallsyms_token_table, . - kallsyms_token_table\n");
 	printf("\n");
 
 	output_label("kallsyms_token_index");
@@ -441,6 +444,7 @@ static void write_src(void)
 			       (unsigned int)table[i]->addr, table[i]->sym);
 		}
 	}
+	printf(".size kallsyms_offsets, . - kallsyms_offsets\n");
 	printf("\n");
 
 	sort_symbols_by_name();

-- 
2.55.0.229.g6434b31f56-goog

Re: [PATCH 1/2] kallsyms: add symbol size for kallsyms symbols that can change size

[Geert Uytterhoeven]

Hi André,

On Tue, 28 Jul 2026 at 14:52, André Draszik <andre.draszik@linaro.org> wrote:
> Add symbol size for kallsyms symbols that can change size so that sizes
> can be determined easily without having to manually calculate them
> when inspecting the object files (.tmp_vmlinux?.kallsyms.o or
> .tmp_vmlinux?). Without, the assembler records the symbol size as 0.
>
> This is primarily useful as a debugging aid in case of linker errors as
> part of link-vmlinux.sh, and because symbol size doesn't have to align
> with the offset to the next symbol due to padding/alignment.
>
> Signed-off-by: André Draszik <andre.draszik@linaro.org>

Thanks for your patch, which is now commit d6bf11a7e8a86135 ("kallsyms:
add symbol size for kallsyms symbols that can change size") upstream.

FTR, this commit has a huge impact on kernel size, according to
bloat-o-meter:

    $ bloat-o-meter vmlinux.{old,}
    add/remove: 4/0 grow/shrink: 0/0 up/down: 440264/0 (440264)
    Function                                     old     new   delta
    kallsyms_names                                 -  324543 +324543
    kallsyms_offsets                               -  114424 +114424
    kallsyms_token_table                           -     849    +849
    kallsyms_markers                               -     448    +448
    Total: Before=5085496, After=5525760, chg +8.66%

However, this seems to be totally bogus, and thus a false-positive:

    $ size vmlinux.{old,}
       text   data    bss    dec    hex filename
    4520823 1507876 154960 6183659 5e5aeb /tmp/vmlinux.old
    4520823 1507876 154960 6183659 5e5aeb /tmp/vmlinux
    $ ls -l vmlinux.{old,}
    -rwxrwxr-x 1 geert geert 7922796 aug 24 14:18 /tmp/vmlinux.old*
    -rwxrwxr-x 1 geert geert 7922796 aug 24 14:19 /tmp/vmlinux*

I also see no change in memory consumption after boot-up, so everything
is good...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 1/2] kallsyms: add symbol size for kallsyms symbols that can change size

[André Draszik]

Hi Geert,

On Mon, 2026-08-24 at 14:26 +0200, Geert Uytterhoeven wrote:
> Hi André,
> 
> On Tue, 28 Jul 2026 at 14:52, André Draszik <andre.draszik@linaro.org> wrote:
> > Add symbol size for kallsyms symbols that can change size so that sizes
> > can be determined easily without having to manually calculate them
> > when inspecting the object files (.tmp_vmlinux?.kallsyms.o or
> > .tmp_vmlinux?). Without, the assembler records the symbol size as 0.
> > 
> > This is primarily useful as a debugging aid in case of linker errors as
> > part of link-vmlinux.sh, and because symbol size doesn't have to align
> > with the offset to the next symbol due to padding/alignment.
> > 
> > Signed-off-by: André Draszik <andre.draszik@linaro.org>
> 
> Thanks for your patch, which is now commit d6bf11a7e8a86135 ("kallsyms:
> add symbol size for kallsyms symbols that can change size") upstream.
> 
> FTR, this commit has a huge impact on kernel size, according to
> bloat-o-meter:
> 
>     $ bloat-o-meter vmlinux.{old,}
>     add/remove: 4/0 grow/shrink: 0/0 up/down: 440264/0 (440264)
>     Function                                     old     new   delta
>     kallsyms_names                                 -  324543 +324543
>     kallsyms_offsets                               -  114424 +114424
>     kallsyms_token_table                           -     849    +849
>     kallsyms_markers                               -     448    +448
>     Total: Before=5085496, After=5525760, chg +8.66%

I suppose the reason is that before the patch each of the above 4
symbols' size was recorded as 0 in the ELF file by the assembler.

With this patch, the assembler places the actual size for each
symbol. Hence they appear to have grown, but in reality they
haven't.

Looking at the delta between each of the symbol's start address with
and without the patch should confirm that, too.

Cheers,
Andre'

Re: [PATCH 1/2] kallsyms: add symbol size for kallsyms symbols that can change size

[Geert Uytterhoeven]

Hi André,

On Mon, 24 Aug 2026 at 15:35, André Draszik <andre.draszik@linaro.org> wrote:
> On Mon, 2026-08-24 at 14:26 +0200, Geert Uytterhoeven wrote:
> > On Tue, 28 Jul 2026 at 14:52, André Draszik <andre.draszik@linaro.org> wrote:
> > > Add symbol size for kallsyms symbols that can change size so that sizes
> > > can be determined easily without having to manually calculate them
> > > when inspecting the object files (.tmp_vmlinux?.kallsyms.o or
> > > .tmp_vmlinux?). Without, the assembler records the symbol size as 0.
> > >
> > > This is primarily useful as a debugging aid in case of linker errors as
> > > part of link-vmlinux.sh, and because symbol size doesn't have to align
> > > with the offset to the next symbol due to padding/alignment.
> > >
> > > Signed-off-by: André Draszik <andre.draszik@linaro.org>
> >
> > Thanks for your patch, which is now commit d6bf11a7e8a86135 ("kallsyms:
> > add symbol size for kallsyms symbols that can change size") upstream.
> >
> > FTR, this commit has a huge impact on kernel size, according to
> > bloat-o-meter:
> >
> >     $ bloat-o-meter vmlinux.{old,}
> >     add/remove: 4/0 grow/shrink: 0/0 up/down: 440264/0 (440264)
> >     Function                                     old     new   delta
> >     kallsyms_names                                 -  324543 +324543
> >     kallsyms_offsets                               -  114424 +114424
> >     kallsyms_token_table                           -     849    +849
> >     kallsyms_markers                               -     448    +448
> >     Total: Before=5085496, After=5525760, chg +8.66%
>
> I suppose the reason is that before the patch each of the above 4
> symbols' size was recorded as 0 in the ELF file by the assembler.
>
> With this patch, the assembler places the actual size for each
> symbol. Hence they appear to have grown, but in reality they
> haven't.
>
> Looking at the delta between each of the symbol's start address with
> and without the patch should confirm that, too.

Correct:

$ diff <(nm -S vmlinux.old | sort ) <(nm -S vmlinux | sort)
--- /dev/fd/63 2026-08-24 15:46:29.404049009 +0200
+++ /dev/fd/62 2026-08-24 15:46:29.404049009 +0200
@@ -34748,11 +34748,11 @@
 0045884a 000000c8 d decpair
 00458912 000000c7 D linux_banner
 004589dc D kallsyms_num_syms
-004589e0 D kallsyms_names
-004a7da0 D kallsyms_markers
-004a7f60 D kallsyms_token_table
+004589e0 0004f3bf D kallsyms_names
+004a7da0 000001c0 D kallsyms_markers
+004a7f60 00000351 D kallsyms_token_table
 004a82b4 D kallsyms_token_index
-004a84b4 D kallsyms_offsets
+004a84b4 0001bef8 D kallsyms_offsets
 004c43ac D kallsyms_seqs_of_names
 00520100 00000070 D stop_sched_class
 00520100 D __sched_class_highest

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH 2/2] kbuild: link-vmlinux.sh: improve detection of third pass requirement

[André Draszik]

It can happen that symbol sizes within .tmp_vmlinux1.kallsyms.o and
.tmp_vmlinux2.kallsyms.o differ, without affecting file size on disk
because of section alignment and/or padding emitted by the assembler.

link-vmlinux.sh doesn't detect this case currently and keeps using
.tmp_vmlinux2.kallsyms.o to link the final vmlinux. Due to the
different symbol sizes, other symbols are shifted within the final
image compared to .tmp_vmlinux2, and the final comparison of System.map
against "${kallsyms_sysmap}" fails with the message:

    Inconsistent kallsyms data
    Try "make KALLSYMS_EXTRA_PASS=1" as a workaround

This can happen in particular if the linker emits additional symbols
that might have different names between our (re-)linking steps, e.g.
because those names depend on the virtual address of the symbol. Linker
stubs for ARM errata work-arounds are one such case.

These changed symbol names can cause the output of the token
compression of kallsyms.c to change due to the changed symbol substring
count, which in turn can change the size of the kallsyms_names symbol
itself, causing the potential shift of subsequent symbol addresses in
.tmp_vmlinux2.kallsyms.o and therefore the final image.

Update link-vmlinux.sh to not rely on file size of
.tmp_vmlinux?.kallsyms.o alone but to also consider symbol offsets
within to resolve this, and do a third pass if required.

Signed-off-by: André Draszik <andre.draszik@linaro.org>

---
The issue was hitting:

In a build with CONFIG_ARM64_ERRATUM_843419=y, the linker adds numerous
instances of __CortexA53843419_<stub target virtual address> stubs
(LLVM in my case). As the second part of the symbol name depends on the
virtual address of the stub target, it changes between .tmp_vmlinux1
and .tmp_vmlinux2.

This change made kallsyms_names bigger by one byte:

-       .byte 0x1c, 0x74, 0xff, 0x43, 0xb9, 0xc3, 0x78, 0x41, 0x35, 0x33, 0x38, 0x34, 0x33, 0x34, 0x31, 0x39, 0x5f, 0x1a, 0x1a, 0x1a, 0x43, 0x30, 0x38, 0x33, 0x41, 0x1a, 0x30, 0x30, 0x34      /* t__CortexA53843419_FFFFFFC083AFF004 */
+       .byte 0x1d, 0x74, 0xff, 0x43, 0xb9, 0xc3, 0x78, 0x41, 0x35, 0x33, 0x38, 0x34, 0x33, 0x34, 0x31, 0x39, 0x5f, 0x1a, 0x1a, 0x1a, 0x43, 0x30, 0x38, 0x34, 0x38, 0x38, 0x46, 0x30, 0x30, 0x34        /* t__CortexA53843419_FFFFFFC08488F004 */

and grew the total size of kallsyms_names from 3879944 to 3879945
bytes. Since this moved it past the four byte alignment, all subsequent
symbols were shifted by 4 bytes, causing the final sanity check to
fail.

$ stat -c'%s' .tmp_vmlinux1.kallsyms.o .tmp_vmlinux2.kallsyms.o
18458168
18458168

$ diff -u <(nm -n .tmp_vmlinux1.kallsyms.o) <(nm -n .tmp_vmlinux2.kallsyms.o)
--- /dev/fd/63	2026-07-28 12:17:55.542466443 +0100
+++ /dev/fd/62	2026-07-28 12:17:55.542466443 +0100
@@ -4,8 +4,8 @@
 0000000000000000 N $d
 0000000000000000 R kallsyms_num_syms
 0000000000000004 R kallsyms_names
-00000000003b340c R kallsyms_markers
-00000000003b50bc R kallsyms_token_table
-00000000003b563c R kallsyms_token_index
-00000000003b583c R kallsyms_offsets
-00000000005806c8 R kallsyms_seqs_of_names
+00000000003b3410 R kallsyms_markers
+00000000003b50c0 R kallsyms_token_table
+00000000003b5640 R kallsyms_token_index
+00000000003b5840 R kallsyms_offsets
+00000000005806cc R kallsyms_seqs_of_names

$ size -A .tmp_vmlinux1.kallsyms.o .tmp_vmlinux2.kallsyms.o
.tmp_vmlinux1.kallsyms.o  :
section              size   addr
.text                   0      0
.rodata           7178673      0
.debug_line            49      0
.debug_line_str        72      0
Total             7178794

.tmp_vmlinux2.kallsyms.o  :
section              size   addr
.text                   0      0
.rodata           7178677      0
.debug_line            49      0
.debug_line_str        72      0
Total             7178798
---
 scripts/link-vmlinux.sh | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index c8f27e4175f9..ab0b8125c8cb 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -106,6 +106,18 @@ vmlinux_link()
 		${kallsymso} ${btf_vmlinux_bin_o} ${arch_vmlinux_o} ${ldlibs}
 }
 
+# Check if kallsymso_prev and kallsymso differ
+# If symbol sizes within ${kallsymso} change, any symbols within vmlinux are
+# likely to shift, invalidating ${kallsymso}.
+# Since file size can remain unchanged even if symbol sizes change, compare the
+# actual symbols instead of relying on file size only.
+kallsymso_changed()
+{
+	${NM} -n "${kallsymso_prev}" > "${kallsymso_prev}.sym"
+	${NM} -n "${kallsymso}" > "${kallsymso}.sym"
+	! cmp -s "${kallsymso_prev}.sym" "${kallsymso}.sym"
+}
+
 # Create ${2}.o file with all symbols from the ${1} object file
 kallsyms()
 {
@@ -126,6 +138,7 @@ kallsyms()
 	${CC} ${NOSTDINC_FLAGS} ${LINUXINCLUDE} ${KBUILD_CPPFLAGS} \
 	      ${KBUILD_AFLAGS} ${KBUILD_AFLAGS_KERNEL} -c -o "${2}.o" "${2}.S"
 
+	kallsymso_prev="${kallsymso:-}"
 	kallsymso=${2}.o
 }
 
@@ -255,7 +268,12 @@ if is_enabled CONFIG_KALLSYMS; then
 	sysmap_and_kallsyms .tmp_vmlinux2
 	size2=$(${CONFIG_SHELL} "${srctree}/scripts/file-size.sh" ${kallsymso})
 
-	if [ $size1 -ne $size2 ] || [ -n "${KALLSYMS_EXTRA_PASS}" ]; then
+	# Due to alignment, file size of the kallsymso object file might remain
+	# unchanged even if individual symbols within change size. Changed
+	# symbol sizes can still shift other symbols, though. Therefore, don't
+	# rely on file size alone.
+	if [ $size1 -ne $size2 ] || kallsymso_changed || \
+			[ -n "${KALLSYMS_EXTRA_PASS}" ]; then
 		vmlinux_link .tmp_vmlinux3
 		sysmap_and_kallsyms .tmp_vmlinux3
 	fi

-- 
2.55.0.229.g6434b31f56-goog

Re: [PATCH 0/2] kbuild: link-vmlinux.sh: more reliable 3rd pass linking

[Nathan Chancellor]

Hi Andre,

> link-vmlinux.sh currently only uses the file size of
> .tmp_vmlinux?.kallsyms.o to determine if it needs to do a third pass. I
> was hitting a case where file size didn't change, but symbols changed
> sufficiently to still move subsequent symbols in vmlinux to invalidate
> kallsyms.
> 
> In particular kallsyms_names grew by one byte between
> .tmp_vmlinux1.kallsyms.o and .tmp_vmlinux2.kallsyms.o, moving the next
> symbol to the next alignment offset (4 bytes), moving many subsequent
> symbols in the final vmlinux image in turn (until abosrbed by further
> alignment instructions). This failed the final link with:
> 
>     Inconsistent kallsyms data
>     Try "make KALLSYMS_EXTRA_PASS=1" as a workaround
> 
> The two patches here are independent of each other:
> * Patch 2 in this series addresses the actual issue and also has a more
>   detailed explanation with exact failure case
> * Patch 1 could be omitted if deemed useless, but I found it useful
>   while debugging the issue. It just updates the kallsyms.c to instruct
>   the assembler to also emit symbol sizes.
> 
> Cheers,
> Andre'
> 
> Signed-off-by: André Draszik <andre.draszik@linaro.org>
> ---
> André Draszik (2):
>       kallsyms: add symbol size for kallsyms symbols that can change size
>       kbuild: link-vmlinux.sh: improve detection of third pass requirement

Thanks a lot for this series! This "Inconsistent kallsyms data" has been
plauging our continuous integration for quite a while but I could never
consistently reproduce the problem enough to actually investigate it. I
have run it through my full test matrix and not noticed any additional
problems. I will continue to hammer on it to see if this message ever
occurs again.

Tested-by: Nathan Chancellor <nathan@kernel.org>

This should probably have some decent soak time in -next to make sure it
does not introduce any regressions. If we do not take it for 7.3 at this
point, I will make sure it gets applied as soon as 7.3-rc1 is out,
aiming to submit it for 7.4.

One note: the diff in the scissor area of second patch makes it fail to
apply.

-- 
Cheers,
Nathan

Re: [PATCH 0/2] kbuild: link-vmlinux.sh: more reliable 3rd pass linking

[Nicolas Schier]

On Tue, 28 Jul 2026 13:42:38 +0100, André Draszik wrote:
> link-vmlinux.sh currently only uses the file size of
> .tmp_vmlinux?.kallsyms.o to determine if it needs to do a third pass. I
> was hitting a case where file size didn't change, but symbols changed
> sufficiently to still move subsequent symbols in vmlinux to invalidate
> kallsyms.
> 
> In particular kallsyms_names grew by one byte between
> .tmp_vmlinux1.kallsyms.o and .tmp_vmlinux2.kallsyms.o, moving the next
> symbol to the next alignment offset (4 bytes), moving many subsequent
> symbols in the final vmlinux image in turn (until abosrbed by further
> alignment instructions). This failed the final link with:
> 
> [...]

Applied to kbuild tree (kbuild-next-unstable), thanks!

[1/2] kallsyms: add symbol size for kallsyms symbols that can change size
      https://git.kernel.org/kbuild/c/bcd29ffd12f8
[2/2] kbuild: link-vmlinux.sh: improve detection of third pass requirement
      https://git.kernel.org/kbuild/c/3ef272de13d4

Please look out for regression or issue reports or other follow up
comments, as they may result in the patch/series getting dropped,
reverted or modified (e.g. trailers).

Patches applied to a kbuild-*-unstable branch are accepted pending
wider testing in linux-next and any post-commit review; they will
generally be moved to the main branch (kbuild-next or kbuild-fixes)
in about a week if no issues are found.

Best regards,
-- 
Nicolas