[RFC] missing #include in frame.h?

[David Carlton]

On Wed, 9 Apr 2003 16:56:11 -0400, Joel Brobecker <brobecker@gnat.com> said:

>> But shouldn't all .c files inculde defs.h first?  (Indeed, that's what
>> GDB Internals says.)  Which file were you compiling when you got this
>> error?  Probably that file should be fixed to include defs.h before
>> frame.h, instead of changing frame.h.

> Ugh (excuse my French). If bla.h depends on defs.h, I think it is wrong
> to ask all c files including bla.h to include defs.h first... But I come
> from the Ada world, so maybe there is a good reason for this?

defs.h is special: we try to avoid all other include ordering
requirements, but not that one.

> I dug a bit further, as my conclusions were a bit premature. Here is one
> include stack example when this happens:

>         In file included from breakpoint.h:25,
>                          from gdbthread.h:29,
>                          from config/nm-lynx.h:49,
>                          from nm.h:24,
>                          from defs.h:767,
>                          from frame.c:23:

> I checked frame.c, and it does include defs.h before frame.h. What
> actually happens is that nm.h is indirectly including frame.h before
> defs.h has included gdbarch.h... (nm.h = config/i386/nm-i386lynx.h,
> which is equivalent to config/nm-lynx.h).

Eek.  That would do it.  An unfortunate chain of inclusions, though.
I don't know anything about nm files, but why is nm-lynx.h including
gdbthread.h at all?  I don't see where that's used in the file, but
maybe I'm missing something.  Also, it seems to me that the target.h
include could be replaced by an opaque declaration of struct
target_waitstatus.

> I think the best approach at this point is really to add the opaque
> structure definition.

Yeah, probably.  Andrew says so too, and obviously he's the one you
should be listening to, anyways!

David Carlton
carlton@math.stanford.edu