From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 593BB46B8 for ; Mon, 14 Nov 2022 11:47:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668426449; 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=e4ZwX5tJJJPTIJIzerD6KiO4OsCFE8SVnZfr4eFI2amch3w9qqTIHIlIhIxOwWyvBv1upT b/QfHlmdM4G5XdLQoBVyJXd8IF+XeF+jwXV2hF1xkK2mmcC3qNplNZ+fbvFFBJT3tr0WtF p6cl8YW1F4LAc4KGG65VsebUiIRcHq0= 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) Precedence: bulk X-Mailing-List: c-std-porting@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: 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 * 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