[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMo8BfLtVWBPv9hiYeWo3CzSqU4SqOTu66_OhEd_GNf_kQaK3g@mail.gmail.com>
Date: Mon, 6 May 2024 16:28:18 -0700
From: Max Filippov <jcmvbkbc@...il.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: [RFC v3 1/1] xtensa: add port
On Mon, May 6, 2024 at 3:55 PM Rich Felker <dalias@...c.org> 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 <dalias@...c.org> 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 <dalias@...c.org> 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.
--
Thanks.
-- Max
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.
