On Fri, Dec 11, 2020 at 07:51:54PM +0100, Claudio Fontana wrote: > On 12/11/20 7:26 PM, Philippe Mathieu-Daudé wrote: > > On 12/11/20 7:22 PM, Richard Henderson wrote: > >> On 12/11/20 12:15 PM, Claudio Fontana wrote: > >>> Should I return this file to the original state (without the extra > >>> #includes that pretend it to be a standalone header file, > >>> and call it > >>> > >>> tcg-cpu-ops.h.inc > >>> > >>> ? > >> > >> If this header can work with qemu/typedefs.h, then no, because the > >> circularity > >> has been resolved. Otherwise, yes. > > > > My editor got confused with TranslationBlock, which is why I asked > > to include its declaration. > > > > Easier to forward-declare TranslationBlock in qemu/typedefs.h? > > > > Regards, > > > > Phil. > > > > Hello Philippe, > > ok you propose to move the existing fwd declaration of TranslationBlock from > cpu.h to qemu/typedefs.h .
It seems simpler to just add a typedef struct TranslationBlock TranslationBlock; line to tcg-cpu-ops.h. Or, an even simpler solution: just use `struct TranslationBlock` instead of `TranslationBlock` in the declarations being moved to tcg-cpu-ops.h. We don't need to move declarations to typedefs.h anymore, because now the compilers we support don't warn about typedef redefinitions: https://lore.kernel.org/qemu-devel/20200914134636.gz1618...@habkost.net/ > > And what about #include "exec/memattrs.h"? > > I assume you propose to put struct MemTxAttrs there as a fwd declaration too, This can't be done, because MemTxAttrs can't be an incomplete type in the code you are moving (the methods get a MemTxAttrs value, not a pointer). > > and this concludes our experiment here? > > Thanks, > > Claudio > -- Eduardo