Il ven 9 gen 2026, 17:21 Pierrick Bouvier <[email protected]> ha scritto:
> > For them, the death of target_long/target_ulong is not really possible, > > because they will have to reinvent include/exec/target_long.h for their > > CPUStates. > > > > At this time, I don't have a simple solution to provide to workaround > this. As long as compilation units are duplicated, you will have > duplicated symbols for any extern symbol, thus preventing to link the > final qemu-system binary. So duplication has to be eliminated, one way > or another. And multiple type definitions is a barrier for this. > Yes, the idea is that if the "single binary" will include both i386 and x86_64 targets, they will both use the TARGET_LONG_BITS==64 version (using it also for the 32-bit target) of CPUState, of the TCG frontend and helpers, etc. IOW the single binary could build a third copy of target/i386, or reuse the x86_64-softmmu one. By making all files for an architecture "common", TARGET_LONG_BITS is > eliminated by design, since it's a poisoned identifier. > Good point. > include/exec/target_long32.h > > ---------------------------- > > #ifndef TARGET_LONG_BITS > > #define TARGET_LONG_BITS 32 > > #endif > > #define TARGET_ADDRESS_BITS 32 > > #define TARGET_LONG_SIZE 4 > > typedef int32_t target_long; > > typedef uint32_t target_ulong; > > #define TARGET_FMT_lx "%08x" > > #define TARGET_FMT_ld "%d" > > #define TARGET_FMT_lu "%u" > > #define MO_TL MO_32 > > > > include/exec/target_long64.h > > ---------------------------- > > #ifndef TARGET_LONG_BITS > > #define TARGET_LONG_BITS 64 > > #endif > > #define TARGET_ADDRESS_BITS 64 > > #define TARGET_LONG_SIZE 8 > > typedef int64_t target_long; > > typedef uint64_t target_ulong; > > #define TARGET_FMT_lx "%016" PRIx64 > > #define TARGET_FMT_ld "%" PRId64 > > #define TARGET_FMT_lu "%" PRIu64 > > #define MO_TL MO_64 > > > > ... and use them in include/exec/target_long.h: > > > > include/exec/target_long.h: > > #ifndef TARGET_LONG_BITS > > #error TARGET_LONG_BITS not defined > > #elif TARGET_LONG_BITS == 32 > > #include "exec/target_long32.h" > > #elif TARGET_LONG_BITS == 64 > > #include "exec/target_long64.h" > > #endif > > > > Then the single-size targets can replace TARGET_LONG_BITS with: > > - a "#define TCG_ADDRESS_BITS" in their translate.c > > - a #include "exec/target_longNN.h" in their cpu.h. > > > > Dual-size targets, instead, can add to their cpu.h an initial stanza > > like this: > > > > #ifdef TARGET_I386 > > #include "exec/target_long32.h" > > #else > > #include "exec/target_long64.h" // x86_64 or single binary > > #endif > > > > and keep using target_long. > > > > I'm not sure what we gain from this header mechanics, wouldn't that be > better to eradicate TARGET_LONG_BITS completely instead? > The problem is that dropping target_long in CPUState would be inefficient. For example i386 registers occupy 32 bytes vs. 256 for x86_64. So I would like to keep 32-bit registers for the 32-bit single-target binary. Compared to the current mechanism, it decouples the choice of TARGET_LONG_BITS from configs/targets/ and makes it possible for target/*/ to pick its preferred length when built for the single binary. But anyway this was just a brain dump—we are in sync for what is needed for this series. With Philippe, we introduced target-info.h, to precisely find this > information at runtime, with target_long_bits(). > As well, as you can see in codebase, target_long_bits() is not used in > many places, and especially, it's not needed anywhere in target/arm. So > it does not seem needed to keep it alive. > I agree that target_long_bits() should be needed almost nowhere (maybe it's needed for VMSTATE_UINTTL migration but not much else) because ideally all use of target_long/ulong would really be confined to target/ and not be in common code. It could be called like an x86_ulong, but it would have to be redone almost the same across all the dual-size targets, hence it's easier to keep the current name and provide a common mechanism. Thanks, Paolo Thanks for the feedback, > Pierrick > >
