On 5/4/25 13:29, Richard Henderson wrote:
On 4/3/25 15:04, Philippe Mathieu-Daudé wrote:
Instead of having a compile-time TARGET_SUPPORTS_MTTCG definition,
have each target set the 'mttcg_supported' field in the TCGCPUOps
structure.
Since so far we only emulate one target architecture at a time,
tcg_init_machine() gets whether MTTCG is supported via the
current CPU class (CPU_RESOLVING_TYPE).
Since TARGET_SUPPORTS_MTTCG isn't available anymore,
instead of emiting a warning when the 'thread' property
is set in tcg_set_thread(), emit it in tcg_init_machine()
where it is consumed.
Signed-off-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Reviewed-by: Anton Johansson <a...@rev.ng>
Reviewed-by: Pierrick Bouvier <pierrick.bouv...@linaro.org>
Reviewed-by: Richard Henderson <richard.hender...@linaro.org>
This doesn't work for i386 and riscv, which have both been "updated" to
initialize cc->tcg_ops via ${arch}_tcg_cpu_accel_type_info ...
static void mttcg_init(TCGState *s)
{
-#ifdef TARGET_SUPPORTS_MTTCG
- bool mttcg_supported = true;
-#else
- bool mttcg_supported = false;
-#endif
+ CPUClass *cc = CPU_CLASS(object_class_by_name(CPU_RESOLVING_TYPE));
+ bool mttcg_supported = cc->tcg_ops->mttcg_supported;
... which has not yet been called, so NULL pointer dereference.
I'm not sure why the init of tcg_ops was moved from ${arch}_cpu_class_init.
Probably it looked nice to remove the #ifdef CONFIG_TCG.
There's a definite ordering problem here, and I'm not sure how to fix it.
Can you just drop this single patch? I'll see what needs to be done.
Thanks,
Phil.
