From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 4sv/Nvyb/WUyohEAWB0awg (envelope-from ) for ; Fri, 22 Mar 2024 10:55:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1711119356; bh=BJzz6OS67bQHX/cTpo//lD/yR9Z2rzhJHFcrgncnuGw=; h=Date:Subject:To:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=H3OWdjyqhl4iRokg9R9NcNWG75lZpmitupmu5Kk/iktDwpBqk6p9KGDd3/8foZ5hp Ejy6RNZhC9QSZfHFKH3GuFW8UzB9iP/21suLjJ0kD6pUJYdEJ8xgIkuvnGjaBiNBg9 eFXQqrp+Sr+n62/L/zZuHwVoChOuAWlTcxQqCZqc= Received: by simark.ca (Postfix, from userid 112) id CF9131E0C0; Fri, 22 Mar 2024 10:55:56 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=N1R82O4d; dkim-atps=neutral Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id A4A461E030 for ; Fri, 22 Mar 2024 10:55:54 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 10C073858415 for ; Fri, 22 Mar 2024 14:55:54 +0000 (GMT) Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id AC1083858D32 for ; Fri, 22 Mar 2024 14:55:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AC1083858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org AC1083858D32 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711119332; cv=none; b=ndBu/8atUgL3c/1iyDYoU+ngQITrO+jmtvV49OC4OUUNzhZvADjOTbJdDPJFSyqgK/pm5O3J+xBSlu7xFzwzsIN7laojzdaX3IDaSTQknmINkLQqp47Oq+kLjfHEwn4G+FQNA5L4Q76XzoiQKG9hAqOkIk4g6dHUE1Yp6vpDEps= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711119332; c=relaxed/simple; bh=BJzz6OS67bQHX/cTpo//lD/yR9Z2rzhJHFcrgncnuGw=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=MJd2LFUNiDZ+n9IHlayahJSVk5vVd2G5xqkjJulHyjeAull2P436ELGRITQMNC8YslAT7xdMt7baYtgzOrZqjaHc+sk14D6aygOvdqipoTE5lowa9KmtXMekdW/pImKElq4nuyidJZNJt+u5mZ/OUn5DGTWtTA9BOdLE7ldZFsA= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1711119326; bh=BJzz6OS67bQHX/cTpo//lD/yR9Z2rzhJHFcrgncnuGw=; h=Date:Subject:To:References:From:In-Reply-To:From; b=N1R82O4ds2Pt7q6hTeSfpJ78RYFmJYiQVdCkJBsSdeVMACuZlaV38PknugyJNx/MD IgYoRe5qinvipmdoBgfyj/J+8RPcbzI6Q+sOQ+Ti3n8cPnuHWIJ7SUaK8dRpGzz9hN TKIEOWPLuhaszYimm0JKvY3kvRAIhsJT+fO9tYBY= Received: from [10.0.0.170] (modemcable238.237-201-24.mc.videotron.ca [24.201.237.238]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 7CDC51E030; Fri, 22 Mar 2024 10:55:26 -0400 (EDT) Message-ID: Date: Fri, 22 Mar 2024 10:55:25 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/3] gdb, gdbserver, gdbsupport: include config.h files with -include To: Pedro Alves , Simon Marchi , gdb-patches@sourceware.org References: <20240318200257.131199-1-simon.marchi@efficios.com> <20240318200257.131199-2-simon.marchi@efficios.com> <2da78531-8a3a-4ac9-a87c-f4962d573fce@palves.net> <9a146cea-3adf-4365-8eb7-60c65d00dcf4@simark.ca> Content-Language: fr From: Simon Marchi In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org 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