From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,HEADER_FROM_DIFFERENT_DOMAINS,HK_RANDOM_FROM, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id EAA8E25418 for ; Tue, 7 May 2024 02:40:35 +0200 (CEST) Received: (qmail 6071 invoked by uid 550); 7 May 2024 00:40:26 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 6030 invoked from network); 7 May 2024 00:40:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715042418; x=1715647218; darn=lists.openwall.com; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=lXjlvshEljqDGdZPhtTnPH+cpILZJcqWUzTXPqttum8=; b=NrU8x0OoskHXWaKROngIeNsJx/41SnNGg4Dc71QwZzadym2eV1knwbb5s58x9hWUfk Fr649IgPGEaE+bJTjXppxPs6wR5J0zqT8p0NuuU+LkUAN6eBUGYxTnP51z8s18mzMm34 4fPrd+IQeUiz8FKkB1vEDakzm1GlOs7NqaT3T46CKRIZylnP6oy57WiHpxaak5gfT4iV XWgjieuVgqm1FHOuMOd+mpUx1Ya9+TM0JEvMv4rzjj9Zc8eyX/XbK0V4ntQao3/W93h1 rGFbRdjIpFQcySh9bfByOaK/vKTixdCe/IZbCC6E2yjMcJ54F6/2X5YsU48XN5IfIc6G J41A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715042418; x=1715647218; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=lXjlvshEljqDGdZPhtTnPH+cpILZJcqWUzTXPqttum8=; b=vfLlNWC/cH/nQeuO5EGvwbQ0P3zGhH0uDr+38VDw6CAdQqJxRPdpiHrSSqyhLfGCW3 ghidueSip3ZkXBSc+wrpaJm44R/RO05ayscTTDOhcL+Ttycp1EpRUNQJ9i28ETCPS+bu vtI9ibxzgN1+zxTdH9/At/wDTJzRRfvbhsMdDbQ0UPdx2ywvfu2HqBT8GOgHe5z4huB8 GSZqf1HHszCtZduNwEG27+G353DQGl4jbxJsVpiBane3/3NuM0EW4V4OBrPOn6VpyulV 9A+Ymez3bDtmkgQ880gem3Y87vpfZL4BrmeE9+HOqwJrtJeXwuDPbk9Yya+IUfwkQO3j jjkA== X-Gm-Message-State: AOJu0Yyp+RwBwtWKuz+CfoKFlKcnPzcEa0sw7QnmJ5U9asGvfAoPuM9N NugXppyS4eVHDfZe1uMTWxjy7I0RsGX/evhzL9cv1Y7AjfCDe88aZG++KqwZqpGDtK8aTvkwmdg ahum+VejBmMVebjqh5Qkepm2IwW0= X-Google-Smtp-Source: AGHT+IE1QOkLNcZmiCqKdUqaWvGb4WVVsqnwxiTUkTcIaUv9C5I9exerecBbLNQugFaEn5BLzislTQw0p2YqR6xL7zs= X-Received: by 2002:a17:90b:3645:b0:2b5:af07:1cde with SMTP id nh5-20020a17090b364500b002b5af071cdemr2241396pjb.34.1715042418189; Mon, 06 May 2024 17:40:18 -0700 (PDT) MIME-Version: 1.0 References: <20240506180112.1045944-1-jcmvbkbc@gmail.com> <20240506180112.1045944-2-jcmvbkbc@gmail.com> <20240506205819.GI10433@brightrain.aerifal.cx> <20240506221524.GJ10433@brightrain.aerifal.cx> <20240506225524.GK10433@brightrain.aerifal.cx> <20240506235901.GL10433@brightrain.aerifal.cx> In-Reply-To: <20240506235901.GL10433@brightrain.aerifal.cx> From: Max Filippov Date: Mon, 6 May 2024 17:40:06 -0700 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] [RFC v3 1/1] xtensa: add port On Mon, May 6, 2024 at 4:58=E2=80=AFPM Rich Felker wrote: > > On Mon, May 06, 2024 at 04:28:18PM -0700, Max Filippov wrote: > > On Mon, May 6, 2024 at 3:55=E2=80=AFPM Rich Felker wr= ote: > > > > > > On Mon, May 06, 2024 at 03:40:49PM -0700, Max Filippov wrote: > > > > On Mon, May 6, 2024 at 3:15=E2=80=AFPM Rich Felker wrote: > > > > > > > > > > On Mon, May 06, 2024 at 02:47:45PM -0700, Max Filippov wrote: > > > > > > On Mon, May 6, 2024 at 1:57=E2=80=AFPM Rich Felker wrote: > > > > > > > > > > > > > > On Mon, May 06, 2024 at 11:01:12AM -0700, Max Filippov wrote: > > > > > > > > diff --git a/arch/xtensa/reloc.h b/arch/xtensa/reloc.h > > > > > > > > new file mode 100644 > > > > > > > > index 000000000000..cd7a455a2d9c > > > > > > > > --- /dev/null > > > > > > > > +++ b/arch/xtensa/reloc.h > > > > > > > > @@ -0,0 +1,32 @@ > > > > > > > > +#if __FDPIC__ > > > > > > > > +#define ABI_SUFFIX "-fdpic" > > > > > > > > +#else > > > > > > > > +#define ABI_SUFFIX "" > > > > > > > > +#endif > > > > > > > > + > > > > > > > > +#define LDSO_ARCH "xtensa" ABI_SUFFIX > > > > > > > > > > > > > > The ldso name is still missing endianness, if it's intended t= hat both > > > > > > > be supported. It needs to completely identify the ABI wheneve= r there > > > > > > > are incompatible ABI variants. > > > > > > > > > > > > For each xtensa core there's only one fixed endianness and code > > > > > > built for one xtensa core is not supposed to be used for any ot= her > > > > > > core, so it's not an issue, right? > > > > > > > > > > Yes, it is an issue. The ldsonames for ABIs must be globally uniq= ue. > > > > > They are intended to be installable in a filesystem shared betwee= n > > > > > multiple archs, possibly even unrelated archs executed via qemu-u= ser > > > > > or similar. > > > > > > > > That means an unbound number of libraries, one per xtensa core > > > > configuration and the solution that comes to mind is using xtensa > > > > core name as a part of ABI name. This is a bit complicated by the > > > > fact that core names are not guaranteed to be globally unique, but > > > > does that sound reasonable in general? > > > > > > Can you describe what the parameter space of core configurations is? > > > > The extensible set of architectural options plus the extensible core > > instruction set plus variable instruction encoding. > > As I said earlier the Tensilica's own approach to it is not to try to f= igure > > out what configurations are compatible with each other but to treat eac= h > > configuration as a separate base ABI and have things like call0/windowe= d > > be the variations of that base ABI. > > > > > Does it actually make mutually incompatible ABIs? If they have the > > > same instruction encoding, endianness, calling convention, etc. they > > > should not be incompatible, but maybe I'm missing something unique to > > > how xtensa works..? > > > > No, most of them fall into one of the big groups of ABIs compatible wit= h > > each other, but it is usually hard to say which ones, especially with t= he > > little information that we have as the end users. And the number of > > groups grows over time and is not limited. > > That kind of thing doesn't need different ldso names. The name needs > to identify the linkage boundary, not any ISA extensions the > application or libc/ldso might be using. I'm not sure I understand what "linkage boundary" means. A barrier that would prevent linking two pieces of code that cannot work together by design? > As an analogy, you could > build i386 musl with -march for intel/sse2 or for amd/k6/3dnow, and > these would be mutually incompatible ISA extensions, but there's > nothing incompatible about the ABI/linkage. I'm not sure how this is compatible with the > > > > > They are intended to be installable in a filesystem shared betwee= n > > > > > multiple archs, possibly even unrelated archs executed via qemu-u= ser > > > > > or similar. If a library built for sse2 cannot run on k6 but may still have the same name, that breaks the filesystem where it is installed, either for intel or for amd, right? In that case that filesystem can only function on intel or on amd. If intel and amd are analogues for two specific xtensa core configurations there's no need to differentiate on the endianness, because each core configuration has single fixed endianness. > Likewise, on arm you might > have some chips that don't support thumb and others that don't support > 32-bit arm instructions, but either way the linkage is compatible and > you can call between them on any environment that supports both. On xtensa systems one cannot choose to build little- or big-endian code for the given core like it is possible to choose whether to build FDPIC or non-FDPIC code. > It sounds like the things that need ldso name distinctions are > endianness, fdpic, and possibly the call0/windowed convention -- I'm > not clear on what that means so I'm not sure. But we should probably > review this in some detail to make sure nothing else is overlooked. Yeah, I guess I'm not clear either. --=20 Thanks. -- Max