[RFC] missing #include in frame.h?

[RFC] missing #include in frame.h?

[Joel Brobecker]

I am trying to see how much effort it needs to be able to build GDB on
LynxOS 4.0, and found that gcc emits the following warning:

    frame.h:698: warning: `struct gdbarch' declared inside parameter list
    frame.h:698: warning: its scope is only this definition or declaration, which is probably not what you want.

I am not sure whether we want to include gdbarch.h or not. Should we?
Or maybe we should be including "defs.h". Shall I go ahead and do that
(add #include "defs.h", and update Makefile.in)?

-- 
Joel

Re: [RFC] missing #include in frame.h?

[David Carlton]

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

> I am trying to see how much effort it needs to be able to build GDB on
> LynxOS 4.0, and found that gcc emits the following warning:

>     frame.h:698: warning: `struct gdbarch' declared inside parameter list
>     frame.h:698: warning: its scope is only this definition or declaration, which is probably not what you want.

> I am not sure whether we want to include gdbarch.h or not. Should we?
> Or maybe we should be including "defs.h". Shall I go ahead and do that
> (add #include "defs.h", and update Makefile.in)?

My impression is that the right thing in these situations is normally
to put an opaque declaration of the struct in question at the top of
the header file:

  struct gdbarch;

That way, header files can be included in any order without forcing
them to include each other.

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.

David Carlton
carlton@math.stanford.edu

Re: [RFC] missing #include in frame.h?

[Andrew Cagney]

> I am trying to see how much effort it needs to be able to build GDB on
> LynxOS 4.0, and found that gcc emits the following warning:
> 
>     frame.h:698: warning: `struct gdbarch' declared inside parameter list
>     frame.h:698: warning: its scope is only this definition or declaration, which is probably not what you want.
> 
> I am not sure whether we want to include gdbarch.h or not. Should we?
> Or maybe we should be including "defs.h". Shall I go ahead and do that
> (add #include "defs.h", and update Makefile.in)?

Add:

	struct gdbarch;

to the start of "frame.h".

Andrew

Re: [RFC] missing #include in frame.h?

[Joel Brobecker]

> My impression is that the right thing in these situations is normally
> to put an opaque declaration of the struct in question at the top of
> the header file:
> 
>   struct gdbarch;
>
> That way, header files can be included in any order without forcing
> them to include each other.

This makes sense. Thanks.

> 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?

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).

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

-- 
Joel

Re: [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

Re: [RFC] missing #include in frame.h?

[Andrew Cagney]

>> 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?

GDB's coding standard stipulates that all .c files include "defs.h" 
first; all other .h files can assume this.

> 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).

Officially, "tm.h" and "nm.h" and "xm.h" are going away.  HP/UX's "tm.h" 
is even worse at this.

My hunch is that, in reality, "nm.h" won't so much go away as be made an 
explicit include by the native files that actually need it.

Andrew