From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43382 invoked by alias); 13 Sep 2018 16:35:02 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 43112 invoked by uid 89); 13 Sep 2018 16:35:02 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: relay1.mentorg.com Date: Thu, 13 Sep 2018 16:35:00 -0000 From: Joseph Myers To: Arnd Bergmann CC: Mao Han , , GNU C Library , Subject: Re: [gnu-csky] [PATCH v4 06/13] C-SKY: Linux ABI In-Reply-To: Message-ID: References: <53924daa4b51c0d552d17d3c5fd9aea09f9fc4b2.1536720821.git.han_mao@c-sky.com> <20180913081721.GB4004@vmh-VirtualBox> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2018-09/txt/msg00194.txt.bz2 On Thu, 13 Sep 2018, Joseph Myers wrote: > On Thu, 13 Sep 2018, Arnd Bergmann wrote: > > > From what I can tell, mips64, riscv64, nios2, and microblaze are all wrong, and > > the generic default would be wrong as well if picked up by anything else (but > > nothing seems to use it). > > A question for cleaning this up and possibly unifying versions of this > header: for multi-ABI architectures, in userspace, what are these > structures meant to refer to? The structures that would be produced by a > core dump for the current process, as opposed to those that might be > produced by a core dump for another ABI? Also, I tried writing a test for the glibc testsuite to verify compatibility of the layout of these structures in the glibc and Linux headers, but found that a simple #include using the installed uapi headers doesn't compile, because of unknown type names size_t, elf_greg_t, elf_gregset_t, elf_fpregset_t, elf_fpxregset_t, pid_t. And indeed, e.g. elf_greg_t is not defined in any of the uapi headers, for many architectures. What are the Linux kernel expectations regarding installed uapi headers actually being usable from userspace without needing additional type definitions provided by the user? If that include worked, and produced the expected layout for the ABI used in the current compilation, it would be very helpful for writing such tests and ensuring bugs in this area can be found and fixed and avoided in future (and more general tests of consistency between glibc and Linux headers are probably possible as long as includes of the Linux headers from make headers_install do reliably compile without external dependencies). -- Joseph S. Myers joseph@codesourcery.com