From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id C77693858D1E for ; Mon, 14 Nov 2022 11:47:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C77693858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668426451; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=RIqTPBbrP6R8hy4JmD+25NWVAzV2MvgdSwq5qPzuB30=; b=QTMOTGP0uGEy1eYh401n8Bs0Sqs3TAFsXrp7Vzdf9mdYmuA7PaBI6On5vR9qh3tJvUu1AF dldvxc9dCVMs/0mFiDDfXfVZ1YFUAhk+J5xN4PBjn1zmov+BaXAJY8V1+10POuhzPv4Tvd HwVb0vk7cVU9M3ubNceWm5mbHn2P19M= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-459-1ubkdgvqMg-aaMIVMAP4_g-1; Mon, 14 Nov 2022 06:47:26 -0500 X-MC-Unique: 1ubkdgvqMg-aaMIVMAP4_g-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 55567811E75; Mon, 14 Nov 2022 11:47:25 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.5]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0EF162166B2B; Mon, 14 Nov 2022 11:47:22 +0000 (UTC) From: Florian Weimer To: Adam Sampson via Libc-alpha Cc: Adam Sampson , Sam James , autoconf@gnu.org, c-std-porting@lists.linux.dev, Zack Weinberg , David Seifert , Gentoo Toolchain , Arsen =?utf-8?Q?Arsenovi=C4=87?= , Paul Eggert , Frederic Berat Subject: Re: On time64 and Large File Support References: <87wn81q254.fsf@oldenburg.str.redhat.com> Date: Mon, 14 Nov 2022 12:47:19 +0100 In-Reply-To: (Adam Sampson via Libc-alpha's message of "Mon, 14 Nov 2022 08:39:02 +0000") Message-ID: <87v8nhwyew.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * Adam Sampson via Libc-alpha: > Florian Weimer via Libc-alpha writes: > >> We should define new target triplets for this if it's really required. > > If the consensus on this does come down to the definition of new > architecture triplets, are there any other changes that should (or > could) be made at the same time, beyond time64 and LFS? I don't think there are any other non-controversial changes for i386-linux-gnu (relative to the current i386-linux-gnu interpretation, i.e. with SSE2 stack alignment). Lots and lots of glibc compat symbols will be dropped, but that should be a transparent change (and something you would be exposed through mere recompilation against current glibc). It seems it would be an opportunity to clean up the Arm triplets and define the ISAs/ABIs for the new ones more tightly than what's been previously used. But I have zero insight into which ISAs/ABIs would be required. I don't know if any of the legacy 32-bit ABIs would benefit from similar clarification. Thanks, Florian