[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMo8BfLZK-NHDD5UmWN4+zK6WKq6CYX+279h5FpS3q4bH4qKCA@mail.gmail.com>
Date: Tue, 7 May 2024 11:41:06 -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 Tue, May 7, 2024 at 9:26 AM Rich Felker <dalias@...c.org> wrote:
>
> On Tue, May 07, 2024 at 08:30:57AM -0700, Max Filippov wrote:
> > On Mon, May 6, 2024 at 6:37 PM Rich Felker <dalias@...c.org> wrote:
> > > 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.
>
> Is there any basic primer on this I could read? I've searched around
> wikipedia, qemu wiki, and various other stuff a bit but haven't found
> answers to any of the questions I would consider relevant.
A bit more is available here:
https://wiki.linux-xtensa.org/index.php?title=Toolchain_Overlay_File
Recently this mechanism was superseded by a dynamic configuration
that may be produced with the following project:
https://github.com/jcmvbkbc/xtensa-dynconfig
> Some exploratory questions I'd like to be able to answer:
>
> - If I use objdump, is it able to decode a baseline set of
> instructions without being given a specific cpu type? If not, what
> keeps it from doing so? (Policy or some kind of ambiguity?)
It's not. Binary encoding of instructions is configuration-specific
and it's done in the configuration overlay code. Although the xtensa
ISA document specifies "core architecture" it's a bit misleading,
because it's not something that every xtensa core has. And there
are instructions that logically belong to the core architecture, but
don't have fixed encoding.
> - If I use gas to assemble an assembly source file, does the output
> depend on a particular configured cpu model? If so, in what way?
It does depend on the configuration. Some assembly constructs
would be relaxed differently depending on the configuration, and
even without relaxation some instructions are going to be encoded
differently for different cores.
> I'm sure there are others like this I'm not thinking of at the moment,
> that would help clarify.
>
> > > > > 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?
> >
> > 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.
>
> Is there actually anything about the dc233c cpu variant that makes up
> part of the linkage boundary?
It's a particular feature set, instruction set and instruction encoding rules.
Toolchain components will be configured for this core and there's no plan
to support linking objects built for different configurations.
> If not, it doesn't belong in the ldso name.
>
> The big problem here (not unique to xtensa) is impedance mismatch
> between the concepts used by the vendor responsible for the arch and
> what musl does. Figuring this out is a big part of making a port
> upstreamable. Given that it's been hard to communicate this, perhaps
> we should work, from the musl side, on having more rigorous
> formulations of the relevant definitions.
--
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.
