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-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id F33231F4B6 for ; Thu, 18 Jul 2019 07:41:54 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; q=dns; s=default; b=TULK i1OLb9JsMFAuSae7FyLs1r53YPZ9QgMGHkgFOt2/IUqcurwSXacZT2uljvhsgupe O4ueNTTbs0w2tBKPIlDPcE6NaU7d2YwxujzHZXaTjhtXjoDAN7ZkmYdJTwzVWW3f x8fyWOde0RC0QKzurebehObruYGNpFWiWhrovc4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; s=default; bh=FRaFHFIyA3 +SBraF/lNGQGEl7GM=; b=MJQrsr2NR2Au8tMNuY+Kaea5UO3piNS6qaKJ2eNf2q y2QaWipNdsKpLzim+mSq8b3OdWuDDcyACNC6HegPLnZjUesaxrctV6wOI+I0G7Nj g/HaD7GGBKgCAKSTPFdztBPZBY3Oi0DT/gpUchGJGqdp8eyXybEC46EdToFfc8zG w= Received: (qmail 36347 invoked by alias); 18 Jul 2019 07:41:52 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 36336 invoked by uid 89); 18 Jul 2019 07:41:51 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-qk1-f193.google.com MIME-Version: 1.0 References: In-Reply-To: From: Arnd Bergmann Date: Thu, 18 Jul 2019 09:41:30 +0200 Message-ID: Subject: Re: [RFC v3 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64 To: Alistair Francis Cc: Alistair Francis , GNU C Library , Adhemerval Zanella , Florian Weimer , Palmer Dabbelt , macro@wdc.com, Zong Li Content-Type: text/plain; charset="UTF-8" On Thu, Jul 18, 2019 at 12:43 AM Alistair Francis wrote: > On Wed, Jul 17, 2019 at 1:27 AM Arnd Bergmann wrote: > > On Wed, Jul 17, 2019 at 2:11 AM Alistair Francis > > wrote: > > > > > +#define __DEV_T_TYPE __UQUAD_TYPE > > > +#define __UID_T_TYPE __U32_TYPE > > > +#define __GID_T_TYPE __U32_TYPE > > > +#define __INO_T_TYPE __UQUAD_TYPE > > > +#define __INO64_T_TYPE __UQUAD_TYPE > > > +#define __MODE_T_TYPE __U32_TYPE > > > +#define __NLINK_T_TYPE __U32_TYPE > > > +#define __OFF_T_TYPE __SQUAD_TYPE > > > +#define __OFF64_T_TYPE __SQUAD_TYPE > > > +#define __PID_T_TYPE __S32_TYPE > > > +#define __RLIM_T_TYPE __UQUAD_TYPE > > > +#define __RLIM64_T_TYPE __UQUAD_TYPE > > > +#define __BLKCNT_T_TYPE __SQUAD_TYPE > > > +#define __BLKCNT64_T_TYPE __SQUAD_TYPE > > > +#define __FSBLKCNT_T_TYPE __UQUAD_TYPE > > > +#define __FSBLKCNT64_T_TYPE __UQUAD_TYPE > > > +#define __FSFILCNT_T_TYPE __UQUAD_TYPE > > > +#define __FSFILCNT64_T_TYPE __UQUAD_TYPE > > > +#define __FSWORD_T_TYPE __SWORD_TYPE > > > +#define __ID_T_TYPE __U32_TYPE > > > +#define __CLOCK_T_TYPE __SLONGWORD_TYPE > > > +#define __TIME_T_TYPE __SQUAD_TYPE > > > +#define __USECONDS_T_TYPE __U32_TYPE > > > +#define __SUSECONDS_T_TYPE __SQUAD_TYPE > > > +#define __DADDR_T_TYPE __S32_TYPE > > > +#define __KEY_T_TYPE __S32_TYPE > > > +#define __CLOCKID_T_TYPE __S32_TYPE > > > +#define __TIMER_T_TYPE void * > > > +#define __BLKSIZE_T_TYPE __S32_TYPE > > > +#define __FSID_T_TYPE struct { int __val[2]; } > > > +#define __SSIZE_T_TYPE __SWORD_TYPE > > > +#define __SYSCALL_SLONG_TYPE __SQUAD_TYPE > > > +#define __SYSCALL_ULONG_TYPE __UQUAD_TYPE > > > +#define __CPU_MASK_TYPE __UQUAD_TYPE > > > > I see you fixed __CLOCK_T_TYPE, but you still have a number > > of types that differ from the kernel ABI for no apparent reason. > > > > Is this intentional? > > Yes, if I use the generic ones for RV32 I see build failures as some > of the structs don't align (I can't remember which ones now). So this > is required to build. I think what it really means is that you have to fix up those build failures by changing the broken code. Using mismatched types to address build failures just replaces them with runtime failures but does not result in a working systems. Arnd