From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) by sourceware.org (Postfix) with ESMTPS id C68F43842400 for ; Fri, 10 Jul 2020 16:55:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C68F43842400 Received: by mail-io1-xd44.google.com with SMTP id l1so6743025ioh.5 for ; Fri, 10 Jul 2020 09:55:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=An/yIdEAolxvVzvTBg+ZxxPu3M6SDW7Hz2zyPmsmYxk=; b=Kj8fOUCx9/vl54Pb7XGCcBmAbGrE0iZH0W4Le7VWbIUkQH2C1NP1BlZFeRGMrfzOBn SKX93BYfpPzmixcFe19Zv+Pzdg4zgdr2ZDXWXXdFxBuJLCJeJv6ZevTlccPmLf2Esead bQ0BEQKWVs3Ndiz3K4ZOYYKXuDxg22e89GD2IfWVxw5mzlnlB9aYZjd+XVzQ16mKBrZZ Rx3LnfIq2Cl4qfK2B3yZxA1eQtBDVRHKGGhLccB8MoaR2iZz3vo1Z+uhEiawzLtH5eGG xNnsAgwAZGCGHHKZkUi8uvilKALDsCyC78sBhJa0TUpEo5mq5VvwpN+DcccyBFaqw7FW lTtw== X-Gm-Message-State: AOAM531IMZfHu4W85G3pG0lC9LA3OOdLt9Gwhvbnx19tyofk5Yf1afpD Yo9TYNxr4BcGvg5s3WV1FZjgvUWGKxql7Deiabul/+MzEdw= X-Google-Smtp-Source: ABdhPJzBdSlbHyubUlQwggZDpicF4zhksRA3jLgBJFm87nmWbXjKvCIw3TG8qg/OvPqKIf5Y0OoabT1X7GbRtDLGP/M= X-Received: by 2002:a5d:9306:: with SMTP id l6mr49478989ion.105.1594400103749; Fri, 10 Jul 2020 09:55:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alistair Francis Date: Fri, 10 Jul 2020 09:45:10 -0700 Message-ID: Subject: Re: [PATCH v2 09/18] RISC-V: The ABI implementation for 32-bit To: "Maciej W. Rozycki" Cc: Alistair Francis , GNU C Library Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-10.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Fri, 10 Jul 2020 16:55:06 -0000 On Thu, Jul 9, 2020 at 4:33 PM Maciej W. Rozycki via Libc-alpha wrote: > > On Wed, 3 Jun 2020, Alistair Francis via Libc-alpha wrote: > > > This patch adds the ABI implementation about 32 bit version. It contains > > the Linux-specific and RISC-V architecture code, I've collected here. > > I think this might be a little better worded, and perhaps discuss briefly > at least some choices made. > > > diff --git a/sysdeps/riscv/bits/wordsize.h b/sysdeps/riscv/bits/wordsize.h > > index faccc71828..ee430d9036 100644 > > --- a/sysdeps/riscv/bits/wordsize.h > > +++ b/sysdeps/riscv/bits/wordsize.h > > @@ -25,5 +25,7 @@ > > #if __riscv_xlen == 64 > > # define __WORDSIZE_TIME64_COMPAT32 1 > > #else > > -# error "rv32i-based targets are not supported" > > +# define __WORDSIZE_TIME64_COMPAT32 0 > > Hmm, this will be problematic on RV64 hardware running mixed RV64/RV32 > userland. This is because files like /var/log/lastlog or /var/log/wtmp > might then be processed by both RV64 and RV32 executables, meaning that > the interpretation will be wrong for executables using the other format. > > We made the wrong choice with RV64, anticipating that `__time_t' will be > 32-bit on RV32 and will have to live with that, by following whatever the > solution is for ports that hold 32-bit time records in the affected > structures. For now I think that means we have to keep the RV32 time > records 32-bit, i.e. set __WORDSIZE_TIME64_COMPAT32 to 1, consistently > with RV64. Aw :( I have changed this so __WORDSIZE_TIME64_COMPAT32 is 1 for both RV64 and RV32. > > I note there is an extensive discussion on the way to move forward here: > > We might as well try to implement it right away, so as to avoid being > limited to 32-bit time records here. Is there an advantage of doing it now or can we put this off for the next release? > > At least these records are not supposed to refer to the future, so > nothing will be broken right now, however if someone for whatever reason > wants to keep a single login record for their system past 2038, then > they'll have an issue (a conversion tool would be straightforward though). > > NB some existing ports do have __WORDSIZE_TIME64_COMPAT32 set and cleared > for their 64-bit and 32-bit ABIs respectively, as per the note in our > top-level bits/wordsize.h, however this reflects the state as before we > introduced the possibility for `__time_t' to be a 64-bit type with > `__WORDSIZE == 32' ABIs. Given the turn of events I think the note ought > to be updated accordingly; I gather it was missed with commit 07fe93cd9850 > ("generic/typesizes.h: Add support for 32-bit arches with 64-bit types"). > > > +# define __WORDSIZE32_SIZE_ULONG 0 > > +# define __WORDSIZE32_PTRDIFF_LONG 0 > > Ack; this matches GCC's . > > > diff --git a/sysdeps/riscv/nptl/bits/pthreadtypes-arch.h b/sysdeps/riscv/nptl/bits/pthreadtypes-arch.h > > index c3c72d6c10..363034c38a 100644 > > --- a/sysdeps/riscv/nptl/bits/pthreadtypes-arch.h > > +++ b/sysdeps/riscv/nptl/bits/pthreadtypes-arch.h > > @@ -32,7 +32,15 @@ > > # define __SIZEOF_PTHREAD_BARRIER_T 32 > > # define __SIZEOF_PTHREAD_BARRIERATTR_T 4 > > #else > > -# error "rv32i-based systems are not supported" > > +# define __SIZEOF_PTHREAD_ATTR_T 32 > > +# define __SIZEOF_PTHREAD_MUTEX_T 32 > > +# define __SIZEOF_PTHREAD_MUTEXATTR_T 4 > > +# define __SIZEOF_PTHREAD_COND_T 48 > > +# define __SIZEOF_PTHREAD_CONDATTR_T 4 > > +# define __SIZEOF_PTHREAD_RWLOCK_T 48 > > +# define __SIZEOF_PTHREAD_RWLOCKATTR_T 8 > > +# define __SIZEOF_PTHREAD_BARRIER_T 20 > > +# define __SIZEOF_PTHREAD_BARRIERATTR_T 4 > > The values are correct, however some of these macros have the same > expansion regardless of the ABI. For clarity please place them outside > the conditional, as other ports do. Fixed. > > > diff --git a/sysdeps/riscv/nptl/bits/struct_rwlock.h b/sysdeps/riscv/nptl/bits/struct_rwlock.h > > index acfaa75e1b..b478da0132 100644 > > --- a/sysdeps/riscv/nptl/bits/struct_rwlock.h > > +++ b/sysdeps/riscv/nptl/bits/struct_rwlock.h > > @@ -32,14 +32,39 @@ struct __pthread_rwlock_arch_t > > unsigned int __writers_futex; > > unsigned int __pad3; > > unsigned int __pad4; > > +#if __riscv_xlen == 64 > > Same concern about the use of `__riscv_xlen' vs `__WORDSIZE' as before. Fixed. > > > int __cur_writer; > > int __shared; > > unsigned long int __pad1; > > unsigned long int __pad2; > > unsigned int __flags; > > +#else > > +# if __BYTE_ORDER == __BIG_ENDIAN > > + unsigned char __pad1; > > + unsigned char __pad2; > > + unsigned char __shared; > > + unsigned char __flags; > > +# else > > + unsigned char __flags; > > + unsigned char __shared; > > + unsigned char __pad1; > > + unsigned char __pad2; > > +# endif > > + int __cur_writer; > > +#endif > > }; > > I note with this change the RV32 structure will use the generic layout as > per sysdeps/nptl/bits/struct_rwlock.h, however regrettably RV64 does not. > Would it make sense to instead have the layout the same between RV64 and > RV32, perhaps by redefining `__pad1' and `__pad2' in terms of `unsigned > long long' (which would have alignment implications though) or otherwise? I'm not sure which one is better. On one hand it seems better to be more generic and therefore RV32 should use the generic interface. On the other hand the more similar they are the better. I'm still leaning towards we should be generic where possible. > > Is there any benefit from having `__flags' and `__shared' (and the > reserve) grouped within a single 32-bit word? I gather there is, given > the lengths gone to to match the bit lanes across the word regardless of > the endianness. But what is it? I have no idea. > > > -#define __PTHREAD_RWLOCK_INITIALIZER(__flags) \ > > +#if __riscv_xlen == 64 > > Again, `__riscv_xlen' vs `__WORDSIZE'. Fixed. > > > +# define __PTHREAD_RWLOCK_INITIALIZER(__flags) \ > > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, __flags > > +#else > > +# if __BYTE_ORDER == __BIG_ENDIAN > > I would suggest using #elif so as to reduce the number of conditionals > and eliminate nesting. Fixed. > > > diff --git a/sysdeps/riscv/sfp-machine.h b/sysdeps/riscv/sfp-machine.h > > index 08a84fd701..aef8c61a67 100644 > > --- a/sysdeps/riscv/sfp-machine.h > > +++ b/sysdeps/riscv/sfp-machine.h > > @@ -22,7 +22,32 @@ > > > > #if __riscv_xlen == 32 > > NB I think it's OK to keep this `__riscv_xlen' reference as soft-fp is > largely an independent subsystem and shared between projects (at least > libgcc and the Linux kernel). No changed here then > > > -# error "rv32i-based targets are not supported" > > +# define _FP_W_TYPE_SIZE 32 > > +# define _FP_W_TYPE unsigned long > > +# define _FP_WS_TYPE signed long > > +# define _FP_I_TYPE long > > Please align the RHS of these to the same column. Fixed. > > > +# define _FP_DIV_MEAT_S(R, X, Y) _FP_DIV_MEAT_1_udiv_norm (S, R, X, Y) > > +# define _FP_DIV_MEAT_D(R, X, Y) _FP_DIV_MEAT_2_udiv (D, R, X, Y) > > +# define _FP_DIV_MEAT_Q(R, X, Y) _FP_DIV_MEAT_4_udiv (Q, R, X, Y) > > + > > +# define _FP_NANFRAC_S _FP_QNANBIT_S > > +# define _FP_NANFRAC_D _FP_QNANBIT_D, 0 > > +# define _FP_NANFRAC_Q _FP_QNANBIT_Q, 0, 0, 0 > > Likewise. There seems to be an established practice for this header > across architectures to have no space between macro arguments or before > the opening parenthesis. This might help with the alignment. I still think it makes sense to follow the glibc style though, even if other archs don't. Let me know if it should be a different way and I'll update it. > > This looks otherwise OK to me (and virtually the same as libgcc's copy, > except for the extra widening operations defined accordingly for FMA). Great! > > > diff --git a/sysdeps/unix/sysv/linux/riscv/jmp_buf-macros.h b/sysdeps/unix/sysv/linux/riscv/jmp_buf-macros.h > > new file mode 100644 > > index 0000000000..7e48f24345 > > --- /dev/null > > +++ b/sysdeps/unix/sysv/linux/riscv/jmp_buf-macros.h > > Shouldn't it go into sysdeps/unix/sysv/linux/riscv/rv32/jmp_buf-macros.h? > > > @@ -0,0 +1,53 @@ > > +/* jump buffer constants for RISC-V > > Please make it a proper sentence. Fixed > > > + Copyright (C) 2017-2020 Free Software Foundation, Inc. > > This is a new file so just 2020 should do. Fixed > > > +/* Produced by this program: > > + > > + #include > > + #include > > + #include > > + #include > > + > > + int main (int argc, char **argv) > > + { > > + printf ("#define JMP_BUF_SIZE %d\n", sizeof (jmp_buf)); > > + printf ("#define JMP_BUF_ALIGN %d\n", __alignof__ (jmp_buf)); > > + printf ("#define SIGJMP_BUF_SIZE %d\n", sizeof (sigjmp_buf)); > > + printf ("#define SIGJMP_BUF_ALIGN %d\n", __alignof__ (sigjmp_buf)); > > + printf ("#define MASK_WAS_SAVED_OFFSET %d\n", offsetof (struct __jmp_buf_tag, __mask_was_saved)); > > + printf ("#define SAVED_MASK_OFFSET %d\n", offsetof (struct __jmp_buf_tag, __saved_mask)); > > + } */ > > Please reformat according to the GNU coding style. Fixed Alistair > > This file is otherwise OK. > > Maciej