On Thu, Oct 22, 2026 at 8:52 PM Anton Johansson via qemu development <[email protected]> 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_*().
Hi I've done that, do I need to post those patches? and indeed working! Except, I need to define target_ulong to be always uint64_t. And I tried it for both riscv/i386. > > 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. > > Just throwing ideas out there, either way the current series is good. > > Series: > Reviewed-by: Anton Johansson <[email protected]> > -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo
