mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Marco Bonelli <marco@mebeim.net>
To: Alexandre Ghiti <alex@ghiti.fr>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "terrelln@fb.com" <terrelln@fb.com>,
	"rostedt@goodmis.org" <rostedt@goodmis.org>,
	"mhiramat@kernel.org" <mhiramat@kernel.org>,
	"mark.rutland@arm.com" <mark.rutland@arm.com>,
	"linux-trace-kernel@vger.kernel.org"
	<linux-trace-kernel@vger.kernel.org>,
	"paul.walmsley@sifive.com" <paul.walmsley@sifive.com>,
	"palmer@dabbelt.com" <palmer@dabbelt.com>,
	"aou@eecs.berkeley.edu" <aou@eecs.berkeley.edu>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>
Subject: Re: Broken 32-bit riscv debug build with ZSTD and FTRACE
Date: Tue, 17 Jun 2025 03:48:40 +0200 (CEST)	[thread overview]
Message-ID: <890717501.210398.1750124920866@privateemail.com> (raw)
In-Reply-To: <df439eb4-4dbd-4f0f-bfd2-27c6b1534f39@ghiti.fr>

I did some digging adding prints to modpost.c, trying to understand the errors
complaining about "local symbol 'xxx' was exported" for now. For reference, I am
using commit 494e7fe591bf834d57c6607cdc26ab8873708aa7 for the broken build and
tag v6.14 for the sane build. Config as per my previous mail:

	export ARCH=riscv CROSS_COMPILE=riscv32-linux-
	make distclean
	make defconfig
	make 32-bit.config
	./scripts/config \
		-e FTRACE \
		-e CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT \
		-d RD_ZSTD \
		-d SECURITY_APPARMOR_INTROSPECT_POLICY \
		-d BTRFS_FS
	make olddefconfig
	make -j vmlinux

It seems like modpost is right: the sanity check for exported symbols fails
because somehow some of the entries of .rela.export_symbol reference wrong
LOCAL symbols. 

Inspecting the sane vmlinux.o built on v6.14 I see:

	$ readelf -W -r vmlinux.o | grep -A10 -F .rela.export_symbol
	Relocation section '.rela.export_symbol' at offset 0x255c28c contains 11089 entries:
	 Offset     Info    Type                Sym. Value  Symbol's Name + Addend
	00000004  0862be01 R_RISCV_32             00000028   system_state + 0
	00000010  0892f901 R_RISCV_32             00000018   static_key_initialized + 0
	00000018  084f0e01 R_RISCV_32             00000014   reset_devices + 0
	00000020  08933601 R_RISCV_32             00000008   loops_per_jiffy + 0
	0000002c  083fcf01 R_RISCV_32             00000110   init_uts_ns + 0
	00000038  08761f01 R_RISCV_32             00000354   wait_for_initramfs + 0
	00000040  084c4c01 R_RISCV_32             00000340   init_task + 0
	00000048  0863e901 R_RISCV_32             00000aca   riscv_cached_mvendorid + 0
	00000050  08423d01 R_RISCV_32             00000af4   riscv_cached_marchid + 0

While for the broken vmlinux.o on 494e7fe5 I see:

	$ readelf -W -r vmlinux.o | grep -A10 -F .rela.export_symbol
	Relocation section '.rela.export_symbol' at offset 0x27aa24cc contains 11425 entries:
	 Offset     Info    Type                Sym. Value  Symbol's Name + Addend
	00000004  fff15b01 R_RISCV_32             00000028   system_state + 0
	00000010  ffeed801 R_RISCV_32             00000018   static_key_initialized + 0
	00000018  fff07d01 R_RISCV_32             00000014   reset_devices + 0
	00000020  00149201 R_RISCV_32             000036ed   .LASF3838 + 0
	0000002c  ffde7c01 R_RISCV_32             00000324   init_uts_ns + 0
	00000038  ffc4c801 R_RISCV_32             00000b3a   wait_for_initramfs + 0
	00000040  000d6801 R_RISCV_32             00011e04   .LASF2005 + 0
	00000048  ffb72201 R_RISCV_32             000012b0   riscv_cached_mvendorid + 0
	00000050  ffd14901 R_RISCV_32             000012da   riscv_cached_marchid + 0

Notice how the 4th and 7th relocation entries reference some .LASFxxx label in
the broken build, but reference loops_per_jiffy and init_task in the sane build.

Those relocation entries seem bogus and point to LOCAL symbols. For example,
for .LASF3838 we have ELF32_R_SYM(rela->r_info) = 0x1492 = 5266, which is:

	$ readelf -s vmlinux.o | grep ' 5266:'
	5266: 000036ed     0 NOTYPE  LOCAL  DEFAULT  178 .LASF3838

So rela->r_info is bad, and when modpost looks at it, it rightfully complains
about the symbol being local. However, rela->r_offset (0x20) seems correct as it
points to __export_symbol_loops_per_jiffy (taken as offset in .export_symbols).
Therefore, we get the weird error message:

	ERROR: modpost: vmlinux: local symbol 'loops_per_jiffy' was exported

Even though loops_per_jiffy is *GLOBAL* and *should* be exported.

FWIW, the call chain is:

	section_rela() -> check_section_mismatch() -> check_export_symbol().

Anyhow, that's all I have for now. Seems like vmlinux.o is being built with
RELA relocations that have bogus r_info. Not sure how, will have to do more
digging if/when I have more time.

--
Marco Bonelli

      reply	other threads:[~2025-06-17  1:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-30 21:40 Marco Bonelli
2025-05-31 11:52 ` Marco Bonelli
2025-06-04 12:44   ` Alexandre Ghiti
2025-06-04 13:52     ` Marco Bonelli
2025-06-06 19:42       ` Marco Bonelli
2025-06-12 12:46         ` Alexandre Ghiti
2025-06-17  1:48           ` Marco Bonelli [this message]

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=890717501.210398.1750124920866@privateemail.com \
    --to=marco@mebeim.net \
    --cc=alex@ghiti.fr \
    --cc=aou@eecs.berkeley.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mhiramat@kernel.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=rostedt@goodmis.org \
    --cc=terrelln@fb.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

all inboxes | Powered by JetHome®