[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gdb-patches
Subject:    [RFC] Sort #includes in gdb
From:       ratmice () gmail ! com (Matt Rice)
Date:       2019-01-28 22:31:00
Message-ID: CACTLOFojoHjRV7LktPuT98PhBNhF=hCxA8nFqxzMSLnyLU_-WA () mail ! gmail ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]