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/[email protected]/
>
> 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
