On 10/5/2026 9:19 AM, Yonggang Luo wrote: > On Tue, Oct 6, 2026 at 12:12 AM Pierrick Bouvier > <[email protected]> wrote: >> >> 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? > > Which part? keeping target_arch as SYS_EMU_TARGET__MAX for user-binary because > The following original code would return -1 for some user-binary > + SysEmuTarget arch = target_info()->target_arch; > + > + if (arch == SYS_EMU_TARGET__MAX) { > + arch = qapi_enum_parse(&SysEmuTarget_lookup, target_name(), -1, > + &error_abort); > + } > + return arch; > So basically assigning any value for the user binary is valid. > SYS_EMU_TARGET__MAX is more explicit as it's related to type SysEmuTarget. > -1 is another option but easy to confuse. > > > For why commit e934c624f32f6f44f427d73a2e6a67e983a02ae6. > "target-info: Statically initialize target_arch" > doing that, I am not sure. >
I guess there is a (good or bad) reason for which sub variants of targets are not reflected in SYS_EMU_TARGET enum. We should double check that before doing any change, as it might have other consequences. > >> >>> "target-info: Statically initialize target_arch" >>> >>>> >>>> Regards, >>>> Pierrick >>> >>> >>> >> > > -- > 此致 > 礼 > 罗勇刚 > Yours > sincerely, > Yonggang Luo
