From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96117 invoked by alias); 28 Jan 2019 22:31:52 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 96108 invoked by uid 89); 28 Jan 2019 22:31:52 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=HX-Received:906, wish X-HELO: mail-ed1-f66.google.com Received: from mail-ed1-f66.google.com (HELO mail-ed1-f66.google.com) (209.85.208.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 28 Jan 2019 22:31:50 +0000 Received: by mail-ed1-f66.google.com with SMTP id p6so14490384eds.0 for ; Mon, 28 Jan 2019 14:31:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Lj0LOCQQwHxiB/72gYTuX4A27VDwZDAaNrpV5/MTgvk=; b=IHRhGh4Ij12QtNCb+JbCywWd3P5GczIFVZqzkTdnq9uzzRmCBZz3LhQPM2s8W2hP5k b1Ox2x8ZNHSviIWGfuq2YvD1QFGSuzKwS6Rp0NZWN1lMxeLrjjkqeyYkObpBNyMPBgpW OwD494Any7im+YbFKgnGXE/WxbbadhOu6zQGsNG/PPoFq79BHMBaQBmR8nHVTfwzUgp2 WuhIMKmBfSo72XVp+pitZWn6BRGFlNdnhRzj4Iz9rb+3Xwlzrlo1CBY+ddIh6w6/um+L BLH05eUugXAZvyE8g7P6Y2t7gM1Awc+t6WtLza76L5dHBDbc61qxK15iYLlQHaywOuW1 npUA== MIME-Version: 1.0 References: <87fttfmnpq.fsf@tromey.com> In-Reply-To: From: Matt Rice Date: Mon, 28 Jan 2019 22:31:00 -0000 Message-ID: Subject: Re: [RFC] Sort #includes in gdb To: Pedro Alves Cc: Tom Tromey , "gdb-patches@sourceware.org" Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg00595.txt.bz2 On Mon, Jan 28, 2019 at 11:08 AM Pedro Alves wrote: > > Hi! > > On 01/26/2019 03:40 PM, Tom Tromey wrote: > > > I did not push this to the buildbot, as I believe it is too large for > > that as well. > > ISTR that you could point the bot at some branch instead of a patch? > > This would seem particularly useful for this patch, given > the potential for breaking native/host-only code. > > > If you want to try building it without running the > > script, it is the branch "submit/sort-includes" in my github. > > > > I did test that the script produces the same output if run twice. > > (Actually it has a buglet where it still updates the ChangeLog the > > second time, but I didn't feel like fixing this.) > > > > Let me know what you think. This does have some possibility of breaking > > the build. > > Yeah, there's a likely chance that this will break some native builds -- there are > some headers that are (or used to be) order dependent. I remember a small number of > patches over the years moving header include order particularly in the > architecture-specific Linux native files, around asm/foo.h, sys/foo.h, headers to > fix the build in some particular kernel/libc version. ISTR > as a particular trouble maker, but I could well be misremembering that one. > I wish I could point at actual code / comments or commits, but I'm not > finding much. :-/ I remember the macros defining PTRACE_GETREGS et al, because they are sometimes defined as an enum, sometimes as a macro, and somewhere that one of those constants was wrong due to a copy/paste error in an ancient version of glibc, so on top of the enum vs define thing, there was some fixing it up, and that fixing up worked somewhat until c++, type checking of enum vs int. I did a bit of looking through the history of glibc, but wasn't able to find this wrongly defined constant. here is at least a bit of stuff referencing the enum/macro constants mayhem. https://reviews.llvm.org/D4366