From: Rich Felker <dalias@libc.org>
To: Max Filippov <jcmvbkbc@gmail.com>
Cc: musl@lists.openwall.com
Subject: Re: [musl] [RFC v3 1/1] xtensa: add port
Date: Mon, 6 May 2024 21:37:59 -0400 [thread overview]
Message-ID: <20240507013758.GM10433@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAMo8BfLF4j_fCx6T=bc3DcOVVqe4tNPpZ6haoeu8B9+tU+8Haw@mail.gmail.com>
On Mon, May 06, 2024 at 05:40:06PM -0700, Max Filippov wrote:
> On Mon, May 6, 2024 at 4:58 PM Rich Felker <dalias@libc.org> wrote:
> >
> > On Mon, May 06, 2024 at 04:28:18PM -0700, Max Filippov wrote:
> > > On Mon, May 6, 2024 at 3:55 PM Rich Felker <dalias@libc.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@libc.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@libc..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.
> >
> > 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 between
> > > > > > multiple archs, possibly even unrelated archs executed via qemu-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 function
> 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.
> > Likewise, on arm you might
> > have some chips that don't support thumb and others that don't support
> > 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?
Rich
next prev parent reply other threads:[~2024-05-07 1:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-06 18:01 [musl] [RFC v3 0/1] xtensa FDPIC port Max Filippov
2024-05-06 18:01 ` [musl] [RFC v3 1/1] xtensa: add port Max Filippov
2024-05-06 20:58 ` Rich Felker
2024-05-06 21:47 ` Max Filippov
2024-05-06 22:15 ` Rich Felker
2024-05-06 22:40 ` Max Filippov
2024-05-06 22:55 ` Rich Felker
2024-05-06 23:28 ` Max Filippov
2024-05-06 23:59 ` Rich Felker
2024-05-07 0:40 ` Max Filippov
2024-05-07 1:37 ` Rich Felker [this message]
2024-05-07 15:30 ` Max Filippov
2024-05-07 16:27 ` Rich Felker
2024-05-07 18:41 ` Max Filippov
2024-05-08 17:39 ` Max Filippov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240507013758.GM10433@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=jcmvbkbc@gmail.com \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).