From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76364 invoked by alias); 20 Dec 2017 16:04:58 -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 76353 invoked by uid 89); 20 Dec 2017 16:04:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=no version=3.3.2 spammy=wellmaintained, well-maintained X-HELO: relay1.mentorg.com Date: Wed, 20 Dec 2017 16:04:00 -0000 From: Joseph Myers To: Palmer Dabbelt CC: , Andrew Waterman , Darius Rad , Subject: Re: RISC-V glibc port v2 In-Reply-To: <20171220072022.26909-1-palmer@dabbelt.com> Message-ID: References: <20171220072022.26909-1-palmer@dabbelt.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-ClientProxiedBy: svr-ies-mbx-02.mgc.mentorg.com (139.181.222.2) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-SW-Source: 2017-12/txt/msg00740.txt.bz2 On Tue, 19 Dec 2017, Palmer Dabbelt wrote: > We're planning on supporting 6 glibc configurations on RISC-V, all of which we > internally run regression tests on: > > * -march=rv64imafdc -mabi=lp64d -- what we expect to be the most used > configuration > * -march=rv64imac -mabi=lp64 -- soft floating point > * -march=rv64imafdc -mabi=lp64 -- soft float ABI, but allowed to use > hardware floating point instruction. This > is like softfp in ARM land. > * -march=rv32imafdc -mabi=ilp32d -- rv32i is a 32-bit ISA > * -march=rv32imac -mabi=ilp32 > * -march=rv32imafdc -mabi=ilp32 But you also define dynamic linker names for the "f" ABI variants (lp64f, ilp32f), so, as per my previous comments, those should be built by build-many-glibcs.py and included in at least some testing. > * Our test suite results are very bad, but I believe this is because we're > running on QEMU's user-mode emulation which is known to be both buggy and > incomplete. I'm bringing up userspace again to produce a more reasonable > test suite run, which will hopefully have a much cleaner run. Full execution test results - meaning on QEMU system-mode emulation or hardware, not user-mode emulation - are definitely needed to judge whether a port is ready for inclusion (I've suggested < 20 architecture-specific FAILs as indicative of a state comparable to other reasonably well-maintained ports). Note that there is no need for the glibc you are testing to be ABI-compatible with any glibc in your userspace's root filesystem, so you don't need to rebuild userspace (if e.g. it's using older glibc with different symbol versions) to test current glibc. It *does* need to be able to find libgcc_s and libstdc++ shared libraries at runtime, but you can copy those into the glibc build directory before running tests. > * I've only added one configuration to build-many-glibcs.py, which I haven't > actually run yet. I'll rectify this, but I wanted to at least get something > out so everyone was on the same page here -- the commit is more of a TODO > than an actual commit. There should be at least one per ABI in there. Additional variants for an ABI (e.g. varying whether hard or soft float is used with a soft-float ABI) are optional, depending on whether you think they provide useful additional coverage of significantly different code in glibc getting built. Such variants should typically only need listing in extra_glibcs so they get built in a "glibcs" build but not a "compilers" build. Depending on the multilib configurations used by GCC you may or may not need as many GCC builds as different ABIs (e.g. MIPS has 24 ABIs, so 24 glibc builds in build-many-glibcs.py, but only 8 separate GCC builds, each with multilibs for 3 ABIs). It's important to make sure that the build is completely clean for the GCC / glibc variants you add, including no failures of compilation tests. (That is, clean given that you substitute a checkout of Linus's git tree for the default release version of Linux - obviously the builds can't be clean from the bots until the Linux 4.15 release comes out.) > * I'm not sure what the right the to do with VDSO_NAME_LINUX_4_15 is. It seems > odd that there's nothing newer than 2.6.29 in there. That probably indicates that any more recent vDSOs added to the Linux kernel used a version number that reflected when people started developing them, rather than the version when they actually got into the kernel. Once it gets into the kernel, the symbol version used for the vDSO by the kernel becomes part of the kernel/userspace ABI, so fixed even if in some sense it's the "wrong" version. If the RISC-V Linux kernel port uses a LINUX_4.15 symbol version for its vDSO, adding VDSO_NAME_LINUX_4_15 seems right to me. > * Many copyright cleanups. Of course, if work on the port goes past 31 December before it's ready to go in, you'll need to update all copyrights to use -2018 ranges. -- Joseph S. Myers joseph@codesourcery.com