Re: GDB's #include file policy

Eli Zaretskii
2001-03-21T15:59:00Z

On Wed, 14 Mar 2001, Andrew Cagney wrote:

> Several recent patches have prompted the question of what guidelines, if
> any, are there for GDB and its include files.
>
> I think the short answer is that it hasn't had one and people have
> simply done what was necessary to keep it building. I'd like to tighten
> this, just a little, so that people don't need to guess what goes where
> so here goes...

I think this should go into gdbint.texinfo. If the text you've posted
is all there is to it, I will convert it to Texinfo and add to the
manual; if not, please tell what else we should have there.

> Outside of "defs.h", GDB header files should try to be self contained
> (struct foo * VS typedef ...). If a header file uses typedefs from
> another GDB header (but not defs.h) then that should really be dragged
> in.

I bumped into one problem with the current headers which I was unable
to solve easily: If you want to declare a prototype for a function
which accepts an argument of the type `enum target_hw_bp_type', you need
to include breakpoint.h, where that enum is defined. However, including
breakpoint.h is not for the faint of heart: it wants to pull in
everybody and their dog, which triggers compiler warnings and other
atrocities.

The above enum is required for any header which declares prototypes of
functions that deal with watchpoints.

After trying several solutions (which didn't work in interesting
ways), I finally gave up after I noticed that all the other files
which needed that simply cheated and declared the argument as an int
instead.

I think such cheats isn't the way we want GDB code to be written.
Perhaps someone could make basic data types defined by breakpoint.h
more accessible.

> (Now the tricky bit) GDB headers should try to avoid sucking in system
> header files.

Why? Unlike GDB headers, including more system headers doesn't really
hurt, as it doesn't cause unnecessary recompilation. And system
headers are idempotent anyway.

The problem with this request is that you might need some definition,
such as size_t, which you cannot have without a system header.

If defs.h is supposed to take care of that, it might be trouble
waiting to happen: someone changes defs.h some day, and then all kinds
of platforms start breaking.

> I think the pratical reality is that
> either "defs.h" will have already dragged the header file in (<stdio.h>)
> or that a .C rather than a .H file should be doing the include.

The latter possibility has a disadvantage of forcing specific order of
header inclusion: you cannot safely include a GDB header before the
system header which defines some of the stuff the GDB header uses.

> "tm.h" and "xm.h" are definitly on the way out.
> "nm.h" is probably heading the same way.

What will replace them?