Re: [PATCH v2 0/3] Inline helpers into Rust without full LTO
Nathan Chancellor <[email protected]>
| Newsgroups | gmane.linux.kbuild.devel,gmane.linux.uml.devel,gmane.linux.ports.arm.kernel,gmane.linux.kernel,gmane.linux.kernel.mm,gmane.linux.kernel.rust |
|---|---|
| Message-ID | <20260326024226.GB2302780@ax162> |
On Sun, Mar 22, 2026 at 08:21:59PM +0100, Miguel Ojeda wrote: > - Clang passes `-Werror=unused-command-line-argument`, which means > under arm (i.e. 32-bit) we get: > > clang: error: argument unused during compilation: '-U arm' [-Werror,-Wunused-command-line-argument] > > And under UML I see: > > clang: error: argument unused during compilation: '-I ./arch/um/include/shared' [-Werror,-Wunused-command-line-argument] > clang: error: argument unused during compilation: '-I ./arch/x86/um/shared' [-Werror,-Wunused-command-line-argument] > clang: error: argument unused during compilation: '-I ./arch/um/include/shared/skas' [-Werror,-Wunused-command-line-argument] > > So we would need e.g. `-Wno-unused-command-line-argument` there > close to the `-Wno-override-module` one, unless Kbuild or > ClangBuiltLinux thinks it is important to keep it for this case. No, I don't think it is worth trying to make -Wunused-command-line-argument work for this command. Just disable it. This mirrors what is being done for cmd_cc_o_bc in the distributed ThinLTO: https://lore.kernel.org/[email protected]/ > On the other hand, regardless of whether we fix this (and another > issue in a separate email found thanks to the UML build), we could > instead add `depends on` listing explicitly the architectures where > this is going to be actually tested. That way maintainers can decide > whether they want to support it when they are ready. Thoughts? > > Cc'ing Nathan, Nicolas, Nick, Bill, Justin, David, UML, ARM. I do agree with some of the concerns that adding an architecure dimension to this is a little complicated. I would rather try to flush out those build problems with patches and keep it enabled for all architectures. At the same time though, I understand that enabling it for the "tier 1" architectures is a low barrier of entry for getting the feature upstream, validated, and distributed to the majority of people that would actually use and depend on it, so I ultimately leave that call up to you. > - If we use the `.bc` extension, we need to add a `.gitignore` for > `.bc` files, and an exception for `kernel/time/timeconst.bc`. > > I guess we will not have too many `bc` scripts in the future for > that to be a problem. On the other hand, we have the chance to use > another extension (either for LLVM bitcode or for `bc` scripts). > > But please let me know on e.g. the Kbuild side if someone has > concerns... No real concern on that front but .gitignore has a command to run when modifying it, which will require a !timeconst.bc in a kernel/time/.gitignore file. Cheers, Nathan