From patchwork Fri Mar 24 11:55:36 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zack Weinberg X-Patchwork-Id: 19720 Received: (qmail 116956 invoked by alias); 24 Mar 2017 11:55:40 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 116946 invoked by uid 89); 24 Mar 2017 11:55:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-23.9 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_SORBS_SPAM, RP_MATCHES_RCVD, SPF_PASS autolearn=ham version=3.3.2 spammy=communication, our, independent X-HELO: mailbackend.panix.com X-Gm-Message-State: AFeK/H1/hRxrh+tVIzp9Y73eyMBvZUcpBLOf7sFmMx+v/9WrpsSNB9h0foYOBJtF8pKFlDuiyhPpDS4Y9ZRsjA== X-Received: by 10.107.140.211 with SMTP id o202mr8644030iod.180.1490356537425; Fri, 24 Mar 2017 04:55:37 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Zack Weinberg Date: Fri, 24 Mar 2017 07:55:36 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: __need macros for communication with compiler-provided headers To: Chris Metcalf Cc: GNU C Library On Thu, Mar 23, 2017 at 11:38 AM, Chris Metcalf wrote: > On 3/22/2017 2:47 PM, Zack Weinberg wrote: >> >> So my suggestion would be that you provide an uapi/arch/int_reg_t.h >> (or something like that; it doesn't matter what the name is) that >> _only_ defines int_reg_t (and names in the implementation namespace) >> and then the glibc headers that need int_reg_t can include that. >> You'll find, when you make this change, that arch/abi.h is suddenly >> quite a bit tidier. >> >> The catch though is that we do need a transition plan. I suspect it's >> not a big deal if old libc headers + new kernel headers start getting >> _all_ of arch/abi.h from the small number of headers that use the >> __need macro, so maybe it can be as simple as "as of version X.Y of >> glibc we require version A.B.C or later kernel headers for Tile." > > > My concern is that we don't want to screw up the namespace for anything > that includes or due to getting all of > . > > How does this change look to you? I don't know enough about how these files are used outside of glibc to do a full review, but that looks like it will work from our end. The change we would make is simply plus a bump to the minimum required kernel-header version for Tile. (This is independent of the minimum required *running kernel* version.) Obviously we would have to wait for arch/intreg.h to be in a released kernel. zw diff --git a/sysdeps/tile/bits/link.h b/sysdeps/tile/bits/link.h index d29725892e..7d03ae2d9f 100644 --- a/sysdeps/tile/bits/link.h +++ b/sysdeps/tile/bits/link.h @@ -20,8 +20,7 @@ # error "Never include directly; use instead." #endif -#define __need_int_reg_t -#include +#include /* Registers for entry into PLT. */ diff --git a/sysdeps/tile/bits/setjmp.h b/sysdeps/tile/bits/setjmp.h index e9efc3b5ef..3123f74752 100644 --- a/sysdeps/tile/bits/setjmp.h +++ b/sysdeps/tile/bits/setjmp.h @@ -26,8 +26,7 @@ #ifndef _ASM -#define __need_int_reg_t -#include +#include typedef __uint_reg_t __jmp_buf[32]; diff --git a/sysdeps/unix/sysv/linux/tile/sys/procfs.h b/sysdeps/unix/sysv/linux/tile/sys/procfs.h index ce3e33ddef..3fb3bc0dff 100644 --- a/sysdeps/unix/sysv/linux/tile/sys/procfs.h +++ b/sysdeps/unix/sysv/linux/tile/sys/procfs.h @@ -32,8 +32,7 @@ #include #include -#define __need_int_reg_t -#include +#include __BEGIN_DECLS