[PATCH 1/2] Makefile: Strip leading spaces when preprocessing generated_defconfig

Tom Rini trini at konsulko.com
Tue Apr 29 21:14:05 CEST 2025


On Tue, Apr 29, 2025 at 12:31:29PM +0000, Yao Zi wrote:
> On Mon, Apr 28, 2025 at 08:49:43AM -0600, Tom Rini wrote:
> > On Mon, Apr 28, 2025 at 03:57:27AM +0000, Yao Zi wrote:
> > > On Sun, Apr 27, 2025 at 10:16:27AM -0600, Tom Rini wrote:
> > > > On Sun, Apr 27, 2025 at 03:46:56PM +0000, Yao Zi wrote:
> > > > > On Sun, Apr 27, 2025 at 05:19:04PM +0200, Heinrich Schuchardt wrote:
> > > > > > Am 27. April 2025 16:50:10 MESZ schrieb Yao Zi <ziyao at disroot.org>:
> > > > > > >Clang's preprocessor may emit extra spaces for lines starting with '#'.
> > > > > > >Lines with these extra characters cannot be handled by Kconfig and will
> > > > > > >be ignored with warnings like,
> > > > > > >
> > > > > > 
> > > > > > 
> > > > > > Do you have an example for reprocing the issue?
> > > > > 
> > > > > Sure,
> > > > > 
> > > > > 	clang-19 -E -nostdinc -P -I . -undef -x assembler-with-cpp \
> > > > > 		configs/starfive_visionfive2_defconfig
> > > > > 
> > > > > or a smaller example for demonstrating the behaviour,
> > > > > 
> > > > > 	cat << EOF | clang -E -P -x assembler-with-cpp -
> > > > > 	# comment line
> > > > > 	normal line
> > > > > 	EOF
> > > > > 
> > > > > and you could see the strange indentation. For reproducing the exact
> > > > > Kconfig warnings,
> > > > > 
> > > > > 	make ARCH=riscv \
> > > > > 		CC='clang-19 --target=riscv64-unknown-linux-musl' \
> > > > > 		starfive_visionfive2_defconfig
> > > > > 
> > > > > (Clang is called clang-19 on my machine)
> > > > > 
> > > > > > Is there an understanding why Clang behaves in this way?
> > > > > 
> > > > > Sadly I have no idea. I guess it may serve for improving
> > > > > human-readability of the preprocessed output.
> > > > 
> > > > This is https://github.com/llvm/llvm-project/issues/78778
> > > 
> > > Thanks for the reference! I did a quick search among LLVM's issues
> > > before sending the patch but didn't find anything useful.
> > > 
> > > Do you think such workaround is acceptable? It seems the link should be
> > > included in commit message as well.
> > 
> > I'd like to see if we can get llvm to fix this moving forward first. Can
> > you please comment on the issue as you're hitting this now too?
> 
> Sure it should be fixed in LLVM and I've left a comment in the issue.
> 
> But even though it's fixed in upstream, it will be nice to have such
> compatibility workarounds for some time to keep compatibile with older
> Clang toolchains, about which my concern is most.

Depending on what the LLVM people say, we can say what / how long of a
workaround to keep in.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20250429/f7b44c4a/attachment-0001.sig>


More information about the U-Boot mailing list