On 3/22/21 2:45 PM, Paolo Bonzini wrote: > On 22/03/21 14:35, Claudio Fontana wrote: >> On 3/22/21 2:31 PM, Paolo Bonzini wrote: >>> On 22/03/21 14:27, Claudio Fontana wrote: >>>> This surprisingly works without moving cpu_reset() to a specific_ss >>>> module, even though accel-common.c is specific_ss, hw/core/cpu.c is >>>> common_ss. How come the call to accel_reset_cpu works? >>> >>> I don't understand the question. Why wouldn't it work? :) >>> >>> Paolo >>> >> >> Heh probably something I forgot or do not understand around the specific_ss >> / common_ss distinction. >> >> I was under the (wrong?) impression that we build some tools or components >> that include common_ss objects, but not specific_ss. >> >> And maybe I am just wrong, and things are simpler than I expected. > > No, all emulators include: > > - some parts of common_ss, compiled once per build. These are files > that do not use target-specific definitions. Other sourcesets also > define once-per-build files, and in fact they end up in common_ss via > the add_all method of sourcesets; softmmu_ss, for example is added to > common_ss under the CONFIG_SOFTMMU condition. > > - some parts of specific_ss, compiled once per target because these > files use target-specific definitions. > > - the entirety of the respective hw/ and target/ sourcesets. > > It is possible to include calls from one sourceset to another (including > from common to specific) as long as the conditions ensure that the > symbol is defined.
I guess this last sentence is the more tricky for me to get: "as long as the conditions ensure that the symbol is defined". > > Paolo > Thanks for the explanation, I would assume that "make check" then would be able to catch such problems? Which targets would I need to build to ensure that any problems with this are detected? Do we cover all of these cases with our gitlab CI? Ciao, Claudio
