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 A2C47213B9 for ; Tue, 7 May 2024 00:15:17 +0200 (CEST) Received: (qmail 20394 invoked by uid 550); 6 May 2024 22:15:11 -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 20359 invoked from network); 6 May 2024 22:15:10 -0000 Date: Mon, 6 May 2024 18:15:24 -0400 From: Rich Felker To: Max Filippov Cc: musl@lists.openwall.com Message-ID: <20240506221524.GJ10433@brightrain.aerifal.cx> References: <20240506180112.1045944-1-jcmvbkbc@gmail.com> <20240506180112.1045944-2-jcmvbkbc@gmail.com> <20240506205819.GI10433@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 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: > > > Signed-off-by: Max Filippov > > > --- > > > Changes v2->v3: > > > - fix semid_ds::sem_nsems type > > > - drop store to GOT entry at offset 12 from arch/xtensa/crt_arch.h > > > - add alignment to all assembly function entry points > > > - add .literal_position directive to vfork > > > > Can you elaborate on what .literal_position does here? > > It's an xtensa-specific assembler directive that indicates where > the assembler may place literals when --text-section-literals > and --auto-litpools options are used. vfork implementation has > two movi instructions that are relaxed into literal loads and thus > may need this hint. I've discovered that it's missing when building > the toolchain with other target options produced build error in > vfork.s OK. > > > 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. Rich