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 78CAD22200 for ; Tue, 7 May 2024 17:31:24 +0200 (CEST) Received: (qmail 24320 invoked by uid 550); 7 May 2024 15:31:19 -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 24282 invoked from network); 7 May 2024 15:31:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715095870; x=1715700670; 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=cnwpPmQ1bqBwcglnV3gZF1Ly6urYPYVgfE24k2RorUw=; b=hUU+raNPJOeD4ce8Mkrj7IrExsrsQUOJskJH3+quaZGQ61USXkJ1/7Kdi/RP/+Amyw t4tMW0ZkHif4kdvQ+rr/Z+nxXmixsVswP0UibCsWw9DMGQhkoxvwjf0xdDPup5fB+IDa wYeONFOjOBuXOSPExqygydCpNNm9ZIlN7ac3AMr+05KlVt+m74gNNzfVTOA0e2CAaJZM 25sLAQJ2wJ+xZh5AZUrodKfZ5m4XOra3j2fJZPO7bx5JL8b0LBZsgcirgjUmrcUqrm5b 3PERigTQjbXV1dnrVrJCDsCeoG5XAlL3oYeLwoPdoNQ4yY5/Bm62gPt74EgXkOZFawdB CdnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715095870; x=1715700670; 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=cnwpPmQ1bqBwcglnV3gZF1Ly6urYPYVgfE24k2RorUw=; b=XlOGA47TZA8bFZdG5Tf1RGtHiQ7mYDLbtWuKtHZQ9Pc2vtw/Ro9/SiT2yQBKbHRI/o AhPOK4tKm4QpIcRo8+vTYCJygYqGlRuUDoynEYWSkoSZ7c6eZ1QoRYMmRqt07tT7I/8r DkyEyAjmgYWmZhlhcLoXDUCvANmVOa8JM8tUoxCE7q/9tMmmLpCINKoNpJ5wO5IWs8+g 69bcBF009JugvoqJQhDX7VCsUhPU+t+FbcCZzxTxswL0lTO59Qijib0ksbMqM2LI+rm+ M62GX24U8m+GxtyGlczc2KHRP/LDfbqN0Jx9ywij0anBic6PFGRtNKsn+0+GDhS8nkm0 SZJw== X-Gm-Message-State: AOJu0Yx0quDFnw1jMCdnSS+16WNN9CHU51lgsZ6LkEC8yaHRZfzB5lwQ WlWUL0fU3EJPiQ7Z0QsmJ2j6gmSAFQoE9yRNeLodRqS5pl+qdQ7DZC0DqsmX0+NtaMjLjVdtcoZ WpxPMwA3pKhcFw7w0G3OAwEhbnfc= X-Google-Smtp-Source: AGHT+IHrxbF8kDCmdPD1bG08uSICfYRHVARcSByZ6H+sclOGiHhq/qFYFnstNUzxDEzMecBcFiir3nCEAp0kVI90Mw8= X-Received: by 2002:a17:90b:2288:b0:2ac:93e8:7dd5 with SMTP id kx8-20020a17090b228800b002ac93e87dd5mr13634824pjb.0.1715095869522; Tue, 07 May 2024 08:31:09 -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> <20240507013758.GM10433@brightrain.aerifal.cx> In-Reply-To: <20240507013758.GM10433@brightrain.aerifal.cx> From: Max Filippov Date: Tue, 7 May 2024 08:30:57 -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 6:37=E2=80=AFPM Rich Felker wrote: > > On Mon, May 06, 2024 at 05:40:06PM -0700, Max Filippov wrote: > > On Mon, May 6, 2024 at 4:58=E2=80=AFPM Rich Felker wr= ote: > > > > > > 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 wrote: > > > > > > > > > > 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 wr= ote: > > > > > > > > > > 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 intend= ed that both > > > > > > > > > be supported. It needs to completely identify the ABI whe= never 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 an= y 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 be= tween > > > > > > > multiple archs, possibly even unrelated archs executed via qe= mu-user > > > > > > > or similar. > > > > > > > > > > > > That means an unbound number of libraries, one per xtensa core > > > > > > configuration and the solution that comes to mind is using xten= sa > > > > > > core name as a part of ABI name. This is a bit complicated by t= he > > > > > > 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 cor= e > > > > 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/win= dowed > > > > be the variations of that base ABI. > > > > > > > > > Does it actually make mutually incompatible ABIs? If they have th= e > > > > > same instruction encoding, endianness, calling convention, etc. t= hey > > > > > should not be incompatible, but maybe I'm missing something uniqu= e 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 wi= th 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 be= tween > > > > > > > multiple archs, possibly even unrelated archs executed via qe= mu-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 func= tion > > 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. This part is not feasible for xtensa: there's no single base instruction set compatible with all xtensa cores of the same endianness. > > > Likewise, on arm you might > > > have some chips that don't support thumb and others that don't suppor= t > > > 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? I believe that in accordance with how Tensilica treats xtensa cores, core configuration should be one of the linkage boundaries, along with the FDPIC/non-FDPIC and call0/windowed. So ldso names would look like xtensa-dc233c-fdpic. --=20 Thanks. -- Max