On Fri, Dec 04, 2020 at 05:07:21PM +0100, Paolo Bonzini wrote: > Il ven 4 dic 2020, 14:54 Claudio Fontana <cfont...@suse.de> ha scritto: > > > On 11/30/20 3:35 AM, Claudio Fontana wrote: > > > Hi all, this is v7 of the i386 cleanup, > > > > This is fairly broken still and I am fixing it up, > > > > but a question arises while hunting bugs here. > > > > Silent bugs are introduced when trying to use code like > > > > #ifndef CONFIG_USER_ONLY > > > > in files that are built in "common" objects, since they are target > > independent. > > > > That should be avoided by poison.h > > I wonder also about the rationale why the cpu code is split between > > > > hw/core/cpu.c and $(top_srcdir)/cpu.c > > > > with one part in common and one part in "target specific". > > > > Mostly historical, cpu.c used to have much more than CPU code (it was > exec.c until a month ago, one of the "historical" core files in QEMU and it > had all the dispatch side of the memory API). I wouldn't mind merging these > two files into one. > > Paolo > > > > What do we gain by having part of the cpu in common? > > > > In some cases we end up going through all sort of hoops because we cannot > > just code everything in hw/core/cpu.c due to the fact > > that we do not see CONFIG_ there. > >
I really prefer to have core files guaranteed to be generic, so we don't risk introducing additional per-target differences in base QOM classes (including TYPE_CPU). The hoops we are having to go through are hoops we must go through if we want a multi-architecture QEMU binary in the future. We don't need to fix everything at once (that's why $(top_srcdir)/cpu.c still exists), but we don't need to make this harder. -- Eduardo
