Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240506221524.GJ10433@brightrain.aerifal.cx>
Date: Mon, 6 May 2024 18:15:24 -0400
From: Rich Felker <dalias@...c.org>
To: Max Filippov <jcmvbkbc@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: [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 <dalias@...c.org> wrote:
> >
> > On Mon, May 06, 2024 at 11:01:12AM -0700, Max Filippov wrote:
> > > Signed-off-by: Max Filippov <jcmvbkbc@...il.com>
> > > ---
> > > 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

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.