This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] Sort #includes in gdb
- From: Matt Rice <ratmice at gmail dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Tom Tromey <tom at tromey dot com>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Mon, 28 Jan 2019 14:31:36 -0800
- Subject: Re: [RFC] Sort #includes in gdb
- References: <87fttfmnpq.fsf@tromey.com> <e132876c-15b3-7c47-f765-5c2db103b38e@redhat.com>
On Mon, Jan 28, 2019 at 11:08 AM Pedro Alves <palves@redhat.com> 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 <asm/ptrace.h>
> 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