On 10/5/2026 9:10 AM, Yonggang Luo wrote: > On Tue, Oct 6, 2026 at 12:03 AM Pierrick Bouvier > <[email protected]> wrote: >> >> On 10/4/2026 12:29 AM, Yonggang Luo wrote: >>> `TARGET_ARCH` identifies a base architecture, not necessarily the full >>> system-emulation target. For example, `mipsel-softmmu` uses >>> `TARGET_ARCH=mips`, >>> which caused `query-target` to report `mips` instead of `mipsel`. >>> >>> Generate `TARGET_SYS_EMU` separately. Softmmu builds use the full target >>> name, >>> as `SysEmuTarget` enumerates system targets. User-mode builds use >>> `TARGET_ARCH`: user target names such as `aarch64_be` and `mipsn32el` do not >>> have corresponding `SysEmuTarget` values. This means `mipsel-linux-user` now >>> reports the base architecture `mips` rather than `mipsel`; its executable >>> name >>> remains unchanged. Initialize `TargetInfo.target_arch` from this token and >>> add >>> a qtest to check the `query-target` result against the target name of the >>> running QEMU binary. >>> >>> Yonggang Luo (4): >>> Revert "target-info: Statically initialize target_arch" >>> Revert "meson: Add TARGET_ARCH to config_target_data" >>> tests/qtest: check query-target architecture >>> target-info: preserve full softmmu target identity >>> >>> meson.build | 11 +++++++++-- >>> target-info-stub.c | 2 +- >>> tests/qtest/qmp-test.c | 13 +++++++++++++ >>> 3 files changed, 23 insertions(+), 3 deletions(-) >>> >> >> Why should we do this for user binaries? Current work around >> single-binary only concerns system binaries, where all targets are >> correctly covered by what exists. > > From my personal point of view, keeping target_arch as > SYS_EMU_TARGET__MAX for user binaries > is a better option. I am doing this is for replica of commit >
Ok, but I'm not sure it answers the why. Could you explain the benefits? > "target-info: Statically initialize target_arch" > >> >> Regards, >> Pierrick > > >
