Peter Maydell <peter.mayd...@linaro.org> writes: > Currently we call gdb_init_cpu() in cpu_common_initfn(), which is > very early in the CPU object's init->realize creation sequence. In > particular this happens before the architecture-specific subclass's > init fn has even run. This means that gdb_init_cpu() can only do > things that depend strictly on the class, not on the object, because > the CPUState* that it is passed is currently half-initialized. > > In commit a1f728ecc90cf6c6 we accidentally broke this rule, by adding > a call to the gdb_get_core_xml_file method which takes the CPUState. > At the moment we get away with this because the only implementation > doesn't actually look at the pointer it is passed. However the whole > reason we created that method was so that we could make the "which > XML file?" decision based on a property of the CPU object, and we > currently can't change the Arm implementation of the method to do > what we want without causing wrong behaviour or a crash. > > The ordering restrictions here are: > * we must call gdb_init_cpu before: > - any call to gdb_register_coprocessor() > - any use of the gdb_num_regs field (this is only used > in code that's about to call gdb_register_coprocessor() > and wants to know the first register number of the > set of registers it's about to add) > * we must call gdb_init_cpu after CPU properties have been > set, which is to say somewhere in realize > > The function cpu_exec_realizefn() meets both of these requirements, > as it is called by the architecture-specific CPU realize function > early in realize, before any calls ot gdb_register_coprocessor(). > Move the gdb_init_cpu() call to there. > > Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
Reviewed-by: Alex Bennée <alex.ben...@linaro.org> -- Alex Bennée Virtualisation Tech Lead @ Linaro
