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 65DA925195 for ; Tue, 7 May 2024 00:55:16 +0200 (CEST) Received: (qmail 24289 invoked by uid 550); 6 May 2024 22:55:10 -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 24230 invoked from network); 6 May 2024 22:55:10 -0000 Date: Mon, 6 May 2024 18:55:24 -0400 From: Rich Felker To: Max Filippov Cc: musl@lists.openwall.com Message-ID: <20240506225524.GK10433@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> 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 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? 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..? Rich