From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118205 invoked by alias); 20 Dec 2017 20:25:19 -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 118144 invoked by uid 89); 20 Dec 2017 20:25:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=no version=3.3.2 spammy=H*M:45f2 X-HELO: mail-pg0-f44.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=MBkq2jOG5kn4/0mFUQFeMJ6Fhz/sUAFTGCgWzIxcop4=; b=eictVCf9jPvrhUk4Cq3+nhH0JMSx+lA7eBg5S1yvuZwXH22dwhonUZ4qI+D4nk7ZDX UJZu37DF33YR+w3pqWq11HudTeFWp40YMHLI9961Z0h6x5iTADHZf1pk4eYGtcTypNWq ZWGcN4yH3Zf/W5SRi9e9rowEGPR3orljgUcm8uIxupDbdy2ofBYy85ob0xmpwBfsumfQ L8HP2LmXiCkYF4VU1irz5MiDBZCFZVAasXxUbbP5fQ4gxxpXbgMjL+c53Wr2EMkE5yrr akXMqboEqNgXBHqCx+qNfCpK1dawltg/YC5fdfajEnm4efimBPq8t999MBhT3nZQuIue nBKA== X-Gm-Message-State: AKGB3mJaxWa58FO+Z2o5GMTUXocxKT/C2YNJSOZqBSRx4pqYmXPLUOIu uEPB7yWvybKROpmYSzHfAXfqRUYgFpo= X-Google-Smtp-Source: ACJfBos+uKAZIT7rrBmSIzY+EnjxzRHkfeSnzPwjpden4zyKnFBOm9DnXMg8GmR//SqJAvpCseZQHQ== X-Received: by 10.101.67.1 with SMTP id j1mr7316723pgq.367.1513801516006; Wed, 20 Dec 2017 12:25:16 -0800 (PST) Date: Wed, 20 Dec 2017 20:25:00 -0000 X-Google-Original-Date: Wed, 20 Dec 2017 12:12:10 PST (-0800) Subject: Re: RISC-V glibc port v2 In-Reply-To: CC: libc-alpha@sourceware.org, Andrew Waterman , Darius Rad , dj@redhat.com From: Palmer Dabbelt To: joseph@codesourcery.com Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2017-12/txt/msg00774.txt.bz2 On Wed, 20 Dec 2017 08:04:50 PST (-0800), joseph@codesourcery.com wrote: > 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. Oh, sorry -- lp64f and ilp32f aren't going to be supported in glibc/Linux, just to reduce the number of ABI combinations. I'll remove them from the v3. >> * 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). OK -- the only reason I've been running user-mode emulation is because that's how our test scripts are setup. I'm working getting enough of a userspace together to run the test suite natively now. We've had this before, there's just nothing based on the 4.15 RC headers and I want to make sure everything absolutely lines up. > 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). We currently support all the glibc targets in a single GCC build and we hope to keep it that way, so hopefully this says a bit easier for us. Thanks, though -- part of the reason I only put one entry in was because I wasn't sure what to do :). > 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.) Makes sense. I'll be sure this is the case. >> * 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. OK, that makes sense. During the Linux submission process it was suggested we use 4.15.0, I guess I'm just a bit surprised we're the only ones wo have something newer than 2.6.29. >> * 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. Sounds good. DJ wrote a copyright checking script, so it should be easy to find everything. Thanks for all the feedback. I'll go through your messages, and though I haven't read them yet I assume we'll be submitting a v3.