From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-4.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 1637C1F55B for ; Fri, 22 May 2020 21:31:35 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E057D398753B; Fri, 22 May 2020 21:31:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E057D398753B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1590183093; bh=bRfbPO+ta/vZnEkTpA5bLvBM24SmgzIK6q0gmBSLetQ=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=uwzCbC9fbSTI2o3sT46sPWC2KXW4m+eBdfxkXyvQMSndNlJLEcBeqNnd1Kc/mTves Iqwah5S0nEbb37VGXZfhS+NkSfZ3jgcU86yFInoTO1ttTEcoXCtZVVlQ7BttzRLxFw Ggu4BlYjhiU8UIc9H09JQ6/kdKRRAui7Olb2nR4k= Received: from mail-pj1-x1043.google.com (mail-pj1-x1043.google.com [IPv6:2607:f8b0:4864:20::1043]) by sourceware.org (Postfix) with ESMTPS id 8C558398750B for ; Fri, 22 May 2020 21:31:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8C558398750B Received: by mail-pj1-x1043.google.com with SMTP id n15so5590759pjt.4 for ; Fri, 22 May 2020 14:31:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=bRfbPO+ta/vZnEkTpA5bLvBM24SmgzIK6q0gmBSLetQ=; b=RdQB9JILGn25WP74G5RzrlQ8Qa+iSc3x2myU/VkyUxbZXoPhi1RB1xEgFTyxVRuqMB Xj6SAKMt8pztT2B23b8a0KcS9loV9kE40Snoy6G47C9o2Cn0pL6WvYJ+lPDoDEAdIAHw f0KxpLFTiNLMN7zauC35mWbCe18DV2bRlhXcwKPUOEhLuXbCsLxzDsCROaOwC2rzuC7d Ga/hjGYpJqczDNzPWUsSM37ONmEbEL/klrbrpztjFSzW+PPq0lRGAPx4wGelBcqvVQ7B aMw18WGgx3kgirxkTEDcNr8d9oCMwWQ0+ukey9M0UBAvYTxazEbwHeHMrucBRgT643CW f7iw== X-Gm-Message-State: AOAM532vVAMYt+2QDeo5NmoR9LFyxvJ0IJLXlPbzBRKMjO9uLKIzyzEu dXd+MRyk/WpF+sg5IcHKuZ8= X-Google-Smtp-Source: ABdhPJxZSOhsmi5sDlk5y7pUVcDtK6iLzJ2aeU8AXHkyg9UShH9QPORcah/bbTfJUbcy5aSu5qVJGw== X-Received: by 2002:a17:902:bb85:: with SMTP id m5mr16260447pls.23.1590183086550; Fri, 22 May 2020 14:31:26 -0700 (PDT) Received: from localhost (g228.115-65-196.ppp.wakwak.ne.jp. [115.65.196.228]) by smtp.gmail.com with ESMTPSA id i128sm7541403pfc.149.2020.05.22.14.31.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 May 2020 14:31:25 -0700 (PDT) Date: Sat, 23 May 2020 06:31:23 +0900 To: Joseph Myers Subject: Re: [PATCH 1/1] Initial support for OpenRISC Message-ID: <20200522213123.GB75760@lianli.shorne-pla.net> References: <20200522113633.209664-1-shorne@gmail.com> <20200522113633.209664-2-shorne@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Stafford Horne via Libc-alpha Reply-To: Stafford Horne Cc: Openrisc , GLIBC patches , Christian Svensson Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" Hello, Thanks for the review. On Fri, May 22, 2020 at 08:56:08PM +0000, Joseph Myers wrote: > On Fri, 22 May 2020, Stafford Horne via Libc-alpha wrote: > > > This patch includes the OpenRISC glibc support for linux. > > This is missing a build-many-glibcs.py update. You always need to include > such an update with a new port, which must build at least one > configuration for each ABI supported by the port (and may build any major > non-ABI variants that seem relevant). build-many-glibcs.py results for > the port must be clean (i.e. no failures in the compilation part of the > testsuite), at least when building with GCC and binutils master (it's OK > if you need features or bug fixes not in the most recent release branches, > although distributors might prefer such fixes to be backported). > Similarly, there should be NEWS and README updates. OK. > New 32-bit ports should preferably be set up to support only 64-bit time > and 64-bit offsets (see ARC and RV32 patch postings for examples). OK. > > diff --git a/sysdeps/or1k/bits/atomic.h b/sysdeps/or1k/bits/atomic.h > > There should be no such file. bits/ is only for installed headers, not > internal ones. See commit de071d199a8578055edf2722114788ae749823aa ("Move > bits/atomic.h to atomic-machine.h (bug 14912).", 11 Sep 2015). OK. > > diff --git a/sysdeps/or1k/nptl/bits/semaphore.h b/sysdeps/or1k/nptl/bits/semaphore.h > > Do you really need this file? See commit > 1270fbaaeebe642db335fccaaf98c82e6647cc0d ("semaphore: consolidate arch > headers into a generic one", 5 May 2020). Likely, not, I will review. > > + # Needed for relro detection > > + libc_commonpagesize=0x2000 > > + libc_relro_required=yes > > See commit cb403c34c6f6e1cce5018864485958cfc2e28906 ("Remove relro > configure test.", 27 Jun 2014). OK. > When you have an old out-of-tree port, it's a good idea to go through > cross-architecture commits from when the port was first created onwards to > identify such global changes that need to be applied to that port. I did try to do this, but it started in 2014 it was hard to pick up everything. I also payed close attention to the riscv and csky ports. > > diff --git a/sysdeps/unix/sysv/linux/or1k/bits/mman.h b/sysdeps/unix/sysv/linux/or1k/bits/mman.h > > You shouldn't have this file. See the comment in > sysdeps/unix/sysv/linux/bits/mman.h (and commit > d3a43e49f342c4663af0fff9d95000cfe26867c3, "Unify many bits/mman.h > headers.", 18 Sep 2018, and commit > 61d8b5feeed36e242a043befe9b11f7f8c294f58, "Share MAP_* flags between more > architectures.", 26 Sep 2018): > > /* These definitions are appropriate for architectures that, in the > Linux kernel, either have no uapi/asm/mman.h, or have one that > includes asm-generic/mman.h without any changes or additions > relevant to glibc. If there are additions relevant to glibc, an > architecture-specific bits/mman.h is needed. */ OK. > > diff --git a/sysdeps/unix/sysv/linux/or1k/configure.ac b/sysdeps/unix/sysv/linux/or1k/configure.ac > > new file mode 100644 > > index 0000000000..505530d5c3 > > --- /dev/null > > +++ b/sysdeps/unix/sysv/linux/or1k/configure.ac > > @@ -0,0 +1,4 @@ > > +GLIBC_PROVIDES dnl See aclocal.m4 in the top level source directory. > > +# Local configure fragment for sysdeps/unix/sysv/linux/or1k. > > + > > +arch_minimum_kernel=3.4.0 > > You'll probably need a newer minimum kernel when requiring 64-bit time > support, until all the fallback for 64-bit time on 32-bit kernels without > the 64-bit-time syscalls is implemented. OK, noted. > > +#undef __ASSUME_SET_ROBUST_LIST > > Are you sure this is never supported on this architecture? > arch/openrisc/include/asm/futex.h appears to have gained > futex_atomic_cmpxchg_inatomic in 4.11, so I'd expect the #undef only to be > for kernels older than that. Sorry, I overlooked this thanks for catching. I added the atomic support to the kernel. > > diff --git a/sysdeps/unix/sysv/linux/or1k/sys/procfs.h b/sysdeps/unix/sysv/linux/or1k/sys/procfs.h > > See commit d62f9ec0cce26a275ec68f4564814041a33395b1 ("Complete > sys/procfs.h unification.", 25 Sep 2018). You shouldn't have an > architecture-specific version of this file; add whatever bits/ headers are > needed instead. OK. > In general, each architecture-specific file needs a justification that > either no generic version exists or the generic one is unsuitable or > suboptimal for this architecture; the default is that we want to use > unified implementations of as many files as possible. This has also been my goal for OpenRISC (use as much generic code as possible), but when going over the original port I missed some of these. I noticed in the last few months since I started fixing up the port that many more architecture specific parts were moved to generic code and I did those moves. I seem to missed everything from before 2019 when I started the port. Thank you for pointing these out. I will work on cleaning this up, testing and posting a new version in a week or two. -Stafford