On 10/22/2026 5:57 AM, Anton Johansson wrote: > On 19/10/26, Pierrick Bouvier wrote: >> When linking multiple targets together, we usually have conflicts with helper >> names. So far, it was solved using ad-hoc renaming, but multiple people >> pointed it >> would be better to have a general mechanism for it, so here it is. >> >> A previous series attempted that: >> https://lore.kernel.org/qemu-devel/[email protected]/, >> but it was relying on (binary) symbol renaming, which is not a portable >> solution. >> Instead, this series approaches the problem from source code directly. >> It requires more change, but it's cleaner IMHO. >> >> Series follows these steps: >> >> First, we make sure all helpers and definition are using HELPER() macro. A >> lot >> of helpers were already defined this way, we just make sure it's exhaustive. >> After that we don't have any 'helper_' left on any target code. This is a big >> change touching the whole codebase, but it's a simple mechanical change. As >> long >> as it compiles and links, we know it's correct. >> >> Then, we introduce the prefix for target helpers. For this , we add a new >> define >> (from meson) that applies to all target related code. It could later be used >> to >> prefix other symbols also, that's why it's not named "TCG". >> >> Finally, we cleanup the previous manual helpers prefix that were added in >> codebase. >> >> Pierrick Bouvier (26): >> target/alpha: define and call helpers using HELPER macro >> target/arm: define and call helpers using HELPER macro >> target/avr: define and call helpers using HELPER macro >> target/hppa: define and call helpers using HELPER macro >> target/i386: define and call helpers using HELPER macro >> target/loongarch: define and call helpers using HELPER macro >> target/m68k: define and call helpers using HELPER macro >> target/microblaze: define and call helpers using HELPER macro >> target/mips: define and call helpers using HELPER macro >> target/or1k: define and call helpers using HELPER macro >> target/ppc: define and call helpers using HELPER macro >> target/riscv: define and call helpers using HELPER macro >> target/rx: define and call helpers using HELPER macro >> target/s390x: define and call helpers using HELPER macro >> target/sh4: define and call helpers using HELPER macro >> target/sparc: define and call helpers using HELPER macro >> target/tricore: define and call helpers using HELPER macro >> tcg: introduce HELPER_INFO macro >> tcg: prefix helpers with target base architecture >> target/alpha: remove explicit target specific prefix >> target/hexagon: remove explicit target specific prefix >> target/hppa: remove explicit target specific prefix >> target/microblaze: remove explicit target specific prefix >> target/or1k: remove explicit target specific prefix >> target/rx: remove explicit target specific prefix >> target/tricore: remove explicit target specific prefix > > Hi, since this allows us to link different targets together with clashing > helper names, what about going one step further to allow symbol > collisions between say riscv32/64 etc.? It would make converting targets > to heterogeoneous emulation much easier since you could just compile > op_helper.c and translate.c twice and select different function pointers > based on target_*(). >
We had this idea also while working on arm/aarch64, and resisted the temptation. That said, it was only because the code was correctly splitted in different files between 32/64 variant. For riscv32/64, I can understand it's a different challenge, and it would be worth exploring the idea if it's not easy to split implementation between 32 and 64 parts. I remember that Richard was more inclined to do the proper refactoring required for other targets though. Regarding current series, when the time come, we can simply replace TARGET_ARCH_PREFIX to use the full target_arch, instead of just target_base_arch. In all cases, if you want to demonstrate this (on one file only to save your time and energy), feel free to send a series exploring this approach so we can talk about it. > When I played around with this I ended up splitting helper.h in to > helper-common.h and helper-target.h, where the latter would get an extra > helper_*_tl32_*() prefix and could be compiled twice. But I recall you > mentioning this might be too much helper magic. > I'm not a big fan of preprocessor usage to create duplicated definition of macros, but it's a personal preference, not a general truth. In case it helps with duplicated compilation of files you mentioned above, feel free to show an example using it. I suspect it won't be needed with current series though. > Just throwing ideas out there, either way the current series is good. > > Series: > Reviewed-by: Anton Johansson <[email protected]>
