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=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, 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 6BE8D25A90 for ; Tue, 7 May 2024 03:37:51 +0200 (CEST) Received: (qmail 15543 invoked by uid 550); 7 May 2024 01:37:45 -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 15505 invoked from network); 7 May 2024 01:37:44 -0000 Date: Mon, 6 May 2024 21:37:59 -0400 From: Rich Felker To: Max Filippov Cc: musl@lists.openwall.com Message-ID: <20240507013758.GM10433@brightrain.aerifal.cx> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [RFC v3 1/1] xtensa: add port On Mon, May 06, 2024 at 05:40:06PM -0700, Max Filippov wrote: > On Mon, May 6, 2024 at 4:58 PM Rich Felker wrote: > > > > On Mon, May 06, 2024 at 04:28:18PM -0700, Max Filippov wrote: > > > On Mon, May 6, 2024 at 3:55 PM Rich Felker wrote: > > > > > > > > On Mon, May 06, 2024 at 03:40:49PM -0700, Max Filippov wrote: > > > > > On Mon, May 6, 2024 at 3:15 PM Rich Felker wrote: > > > > > > > > > > > > On Mon, May 06, 2024 at 02:47:45PM -0700, Max Filippov wrote: > > > > > > > On Mon, May 6, 2024 at 1:57 PM 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 that both > > > > > > > > be supported. It needs to completely identify the ABI whenever 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 other > > > > > > > core, so it's not an issue, right? > > > > > > > > > > > > Yes, it is an issue. The ldsonames for ABIs must be globally unique. > > > > > > They are intended to be installable in a filesystem shared between > > > > > > multiple archs, possibly even unrelated archs executed via qemu-user > > > > > > 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 figure > > > out what configurations are compatible with each other but to treat each > > > configuration as a separate base ABI and have things like call0/windowed > > > 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 with > > > each other, but it is usually hard to say which ones, especially with the > > > 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 between > > > > > > multiple archs, possibly even unrelated archs executed via qemu-user > > > > > > 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. It means you can install a libc that is compatible with either one by refraining from building it with extensions that preclude using it with both. > > 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. Indeed. Little- and big-endian are incompatible ABIs via how they define the representation of types differently. FDPIC and non-FDPIC are incompatible ABIs via how the calling convention and representation of function pointers differ. Do these answers help clarify what linkage boundary means above? Rich