Re: [PATCH 2/3] gdb, gdbserver, gdbsupport: include config.h files with -include

[Simon Marchi <simark@simark.ca>]

On 3/21/24 08:50, Pedro Alves wrote:
> On 2024-03-21 02:11, Simon Marchi wrote:
>> On 3/20/24 16:32, Pedro Alves wrote:
>>> On 2024-03-18 20:01, Simon Marchi wrote:
>>> Note there is a make rule to check whether gdb headers are standalone.  "make check-headers".
>>> Unfortunately, nobody ever runs that ( me included, after adding it a decade ago :-P ).
>>> Ideally, we'd fix all it flags and run it (or something like it) once in a while in a CI.
>>> (And same for gdbserver/gdbsupport, of course.)
>>
>> Ah! I probably saw that in the past but forgot about it.  It might need
>> to be changed too, depending on what follows.
>>
>>>> This patch does the small step of moving the inclusion of the various
>>>> config.h files to that new method.  The changes are:
>>>>
>>>>  - Add three files meant to be included with -include: gdb/gdb.inc.h,
>>>>    gdbserver/gdbserver.inc.h and gdbsupport/gdbsupport.inc.h.
>>>>  - Move the inclusion of the various config.h files there
>>>>  - Modify the compilation flags of all three subdirectories to add the
>>>>    appropriate -include option.
>>>
>>> I'm surprised by the actual patch.  Why isn't this including defs.h/common-defs.h?  There are
>>> surely things defined in those files that need to be defined in headers too.  Why create
>>> this divergence?  I'd think that we would include defs.h/common-defs.h in headers too, and
>>> then work on moving things out of defs.h/common-defs.h over time.
>>
>> I am not sure I understand what you mean.  If a given header file uses
>> something defined in defs.h, then it should include defs.h.  Otherwise
>> it doesn't need to.  Maybe if you give a concrete example I will get
>> your point better.
>>
> 
> I think you're looking at this all backwards, TBH.  

Thanks a lot for the feedback.  TLDR, I agree with you.

> 
> Currently, defs.h (and common-defs.h/server.h...) is a special header, and we need to include it first.
> 
> We all agree that defs.h includes too much, and that several things in it should be moved to other headers, and included
> only where they're needed.  If we imagine we've already done that, then defs.h is left with only the things that
> need to be included by all source files, and all headers.
> 
> That's the end goals that seems super obvious to me.
> 
> Yet, your patch takes a different route, and creates yet another set of special headers, and moves some things there.

To be clear, after my series, defs.h is no longer special.  It just
happens that headers that need it rely on it having been included
before.  I didn't see it as an immediate problem (it still builds),
because there are a lot more instances of that problem anyway (cases
that make check-headers would catch).  I saw it as something we would
fix little by little.

> It then leaves us in a partial transition state, where it's very likely that some headers needed more things that are
> included by defs.h, but they aren't included in the new magic header, nor in the said headers that needed the things.
> I.e., it likely regresses "make check-headers" even further.  Some headers use bfd_vma for example.  Are they all including
> libbfd.h explicitly or transitively?  I don't know.  Currently they get it from defs.h.  Some headers make use
> of "enum block_enum", which is defined in defs.h today, so when you edit such headers you'll will not have that
> enum defined.  Likewise probably other enums in defs.h.  We use gdb::array_view in a lot of headers, etc.

Right, my series doesn't actually make it better when I look at header.
But it makes it so the errors make sense, and I can start fixing them.
Whereas right now, the errors given in the headers sometimes don't make
sense, because we're missing some magic things from the various config.h
files, for instance.

> I really see no reason for the new headers, and switching to a different set of magic headers, and moving things around
> from defs.h to the new headers.  It makes me a bit nervous even, as order of some things in defs.h (and friends) is important.
> E.g., the GCC_GENERATED_STDINT_H thing.

My hope was that we could identify in one go all the stuff that needs to
be included or defined early, and put it in a new, clean header.  But
of course that's risky, it looks like GCC_GENERATED_STDINT_H would
belong in the early include file too.

> What I'm saying is that the patch that I was expecting to see, was one that simply does one thing -- makes gdb use "-include" to
> force-include defs.h everywhere (and common-defs.h/server.h, you get the point).  It's then just one single, atomic, change.  We go
> from having to put defs.h at the top of source files, to not having to do that because we use "-include defs.h".  That's it.  Nothing more.
> So defs.h is still the same special header, just the mechanism by which we include it changes.  The code that ends up compiled is
> _exactly_ the same.  Documentation explaining that that is the special header doesn't have to change.

I think that makes sense.  It's clearly less risky than my approach.  It
has the advantage that editing headers should work fine right away.

> And your use case, editing the header, will end up with headers including _exactly_ what they include today when any source
> file is compiled, not some subset of defs.h.  Any oddity with editing the file is an oddity normal compilation would have too.
> 
> And then, over time, we move things out of defs.h.  E.g., move to including array-view.h in headers that need it.  Move
> the definitions of enum block_enum, enum user_selected_what_flag, etc. to some other headers that make more sense.  Move the inline
> functions and function prototypes to other headers.  Etc.  But we take it from the top down.  Ultimately still end up with defs.h,
> but a smaller defs.h.  
> 
> And at each step of the way, editing a header file always sees the exact same set of pre-included files/symbols as when the same header
> is compiled normally.

Ack, thanks!

Simon