On Mon, Apr 03, 2023 at 06:35:45PM +0200, Miguel Ojeda wrote: > On Thu, Mar 30, 2023 at 11:12 AM Conor Dooley > <conor.dooley@xxxxxxxxxxxxx> wrote: > > > > I'd rather do this in the RISC-V Makefile so that it does not get > > forgotten. > > Sounds good to me! We want to have the least amount of things possible > in the common pieces (e.g. for the target spec file we moved some > flags); so the more we move out to `arch/`, the better. > > > If my understanding of bindgen is correct, we don't actually need to be > > honest to it about what extensions the rest of the kernel is compiled > > with, only make sure that it is not called with arguments it does not > > understand? > > As long as bindgen generates things with the right ABI etc., yeah. > But, in principle, enabling one extension one side but not the other > could be wrong if it ends up in something that Rust uses, e.g. if the > C side does: > > #ifdef __ARM_ARCH_7R__ > int x; > #else > char x; > #endif > > and Rust attempts to use it, then particular `-march` builds could be broken. To be on the safe side then, we should really disable the extensions across the whole kernel. I don't *think* we have any madness at the moment like in the above, but it is better to be on the safe side. As I note below, it's just one extension for now anyway. > > What version of GCC do I need to replicate this? I can build tip-of-tree > > gcc if needs be. > > Sorry, what do you want to replicate? If you mean what we had in the > old GitHub CI, I see: > > CONFIG_CC_VERSION_TEXT="riscv64-linux-gnu-gcc (Ubuntu > 11.3.0-1ubuntu1~22.04) 11.3.0" > > which successfully boots in QEMU for the kernel config we tested. No, I misunderstood your question. I thought you meant something else entirely. > But if you are asking what should be supported, I guess it depends on > the RISC-V maintainers. Ideally, everything that the kernel supports > (GCC >= 5.1), Heh, as if that number is true across the board! > but since the GCC+Rust builds are so experimental, I > think as long as something is tested from time to time, it would be > great (to at least know not everything is completely broken). > > But if you think that would be too much effort to maintain, or even > GCC builds in general, then please feel free to ignore it for the time > being, i.e. it is better to have LLVM builds rather than nothing! :) Yeah, it may be worth getting just the LLVM bits in. I abhor the -march handling and it may end up looking like shite with the zicsr & zifencei handling. Worst comes to worst, can permit gcc builds by just removing all the extensions that get passed in -march for RUST && CC_IS_GCC type scenarios. The only one of those at the moment is zihintpause & I don't suppose too many tears will be shed over that. For now it's safe to assume that LLVM doesn't require zicsr or zifencei [1], we don't need to do a version dance right away. ¯\_(ツ)_/¯, Conor. 1 - https://reviews.llvm.org/D147183#4233360
Attachment:
signature.asc
Description: PGP signature
