While we strive to get multiarch ready for squeeze, there is currently nothing
to point to what the multiarch tuples actually mean, neither on the Debian side
nor on some kind of standards side like the FHS or LSB.  This has to be
documented on the Debian side, and better be incorporated into standards like
the FHS or LSB.

The current state is http://wiki.debian.org/Multiarch/Tuples, deriving from
http://wiki.debian.org/Multiarch/TuplesAbandoned. An email to debian-ports
didn't get any feedback. From my point of view such a wiki page should be
self-contained and be usable as a reference for upstream projects.  My current
concern is that upstream builds of GCC and binutils are currently broken and
patch submissions to GCC are on hold until such a definition is available at
least on the Debian side.

Matthias Klose wrote:
many of which are almost certainly wrong):

 i386-linux-gnu: Intel ia32 ABI, ELF, Linux syscalls, glibc 2.x.
	psABI is documented in the System V ABI Intel386 architecture
	processor supplement: http://www.sco.com/developers/devspecs/

 x86_64-linux-gnu: Likewise, but using the AMD64 psABI as documented
	in abi.pdf: http://x86-64.org/documentation/

 sparc-linux-gnu: Likewise, but with the SPARC psABI as documented
	in psABI3rd.pdf: http://www.sparc.com/standards/
	Debian uses the v8plus ABI, but I think that is
	backward-compatible with the old svr4 ABI and doesn't have to be
	part of the definition.

 sparc64-linux-gnu: Likewise, but with the SPARC v9 64-bit psABI.
	Not sure where the reference documentation is for that.

 alpha-linux-gnu: Likewise, but with the Tru64 UNIX Calling Standard
	for Alpha Systems:
http://www.openwatcom.org/ftp/devel/docs/alpha%20calling%20standard.pdf

 m68k-linux-gnu: Likewise, but with the Motorola 68000 Family
	Processor Supplement to the System V ABI which doesn't seem to
	be available oneline. (?)

 arm-linux-gnueabi: ARM's "new" GNU EABI for Linux, soft float, 32 bit.
	Documented at http://wiki.debian.org/ArmEabiPort which refers to
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042a/IHI0042A_aapcs.pdf
http://www.codesourcery.com/gnu_toolchains/arm/arm_gnu_linux_abi.pdf

 arm-linux-gnueabihf: likewise but with hard float

Jonathan Nieder <jrnieder@gmail.com> writes:

Did you read the wiki page?

If I had to define the multiarch tuple I would say:

The multiarch tuple uniquly defines the calling convention used in a
binary or library. For convenience the first GNU triplet implementing a
calling convention is used where possible or suitably extended to remain
unique.

If there are multiple libraries with different ABIs but with the same
calling convention (e.g. i386, i486, i586, ...) so that they can be
interchanged without binaries needing to be recompiled then they share a
multiarch tuple (i386-linux-gnu).

On the other hand if one ABI has multiple calling conventions (hard/soft
floats on arm) then the multiarch tuples must differ for each calling
convention.

MfG
        Goswin

Goswin von Brederlow wrote:
system library structures, and so on form the ABI for a given tuple
that I was giving examples of not what the upstream gcc folks were
looking for?  I'm not sure I understand the point of your question.

Ah, maybe this is where we are talking past each other: I read this as
a request to pin down and document the definition of each multiarch
tuple.  Perhaps you read it as a request to pin down and document the
definition of the term "multiarch tuple", without necessarily pinning
down the details for each arch.

It would certainly be useful to clarify which is needed before
deciding which to spend time on, so thanks for asking.  Matthias?

Thanks for a useful clarification.
Jonathan

first thing would be the documentation of each tuple currently used by Debian
(including the ones used for the non-default biarch multilibs). If we can come
up with a definition of "multiarch tuple" later that's fine, but given that we
did abandon the earlier approach I'm not sure that's possible.

   Matthias

Matthias Klose <doko@debian.org> writes:

Should we even have biarch in the multiarch world?

The biarch libs and foreign libs installed through multiarch implement
the same ABI/calling convention/functionality. They are basically
interchangable.

To make them truely interchangable the multiarch tuple for biarch libs
should be the same as they would have if they were the native
one. E.g. the i386-linux-gnu for 32bit libs on amd64 [using amd64 as
example from now on]. And they should use the same paths. If there is no
native equivalent for some biarch lib then just make up some multiarch
tuple based on the gnu triplet. The only thing that matters is that it
uniquly identifies the calling convention of the lib.


For Debian (wheezy+x) I would like to see gcc-multilib depend on
libc6:i386 instead of libc6-i386. Or maybe remove multilib support
alltogether and use i486-linux-gnu-gcc (a cross compiler) instead. gcc
-m32 could remain for compatibility but call i486-linux-gnu-gcc.

After all with multiarch having anything build for 32bit in amd64 is
wastefull as it just duplicates the package already in i386. Same with
ppc / ppc64, ...

MfG
        Goswin

multilib libraries should continue to build.

no. adding cross-architecture build dependencies doesn't add to the build
stability. The possibility to call another version or target compiler from the
driver was removed upstream, so I doubt somebody want to re-add it again, and I
won't carry this as a downstream patch (so please get the done in stage1 for 4.8
if you are interested in that).

yes, but you are quick to waste my own time. Patches which do not go upstream do
require an extra maintenance effort as seen for the split build (gcc, gcj, ...)
and the hardening patches.  A lot of multilib packages can be dropped,
but the ones built from gcc and glibc should continue to build.

Matthias Klose <doko@debian.org> writes:

Time will tell.

Nobody is talking about cross-architecture build dependencies.

As said building 32bit stuff on amd64 in the multiarch world is
pointless. The same stuff can just be gotten from i386 directly.

And if no source builds 32bit stuff on amd64 then we do not need
multilib.

And if nothing needs multilib then you do not need to build it and thus
do not need to build-depend on cross-architecture stuff to build it.

Fair enough. Overall it would make no sense that I have to call
armel-linux-gnu-gcc to build for arm but gcc -m32 to build for i386 in a
multiarch world [again example with amd64 as native arch].

Nobody is holding a gun to your head and forcing you to invest any
time. Although I would say dropping multilib would rather safe you a lot
of time and maintainance effort than cost you anything. And since
multilib is enabled in debian/* there is no patch that would need to go
upstream.

Wheezy+x is a long way in the future so lets just wait and see. There is
still a lot of work to do for multiarch before dropping multilib support
from gcc can even be considered. No point arguing about that now.

MfG
        Goswin

I've updated http://wiki.debian.org/Multiarch/Tuples with lots more
information such as links to external ABI specs where I could find
them. I based this on Jonathan Nieder's initial email (thanks!) and
filled in from there. For the non-Linux ports a bit more help would be
useful; I don't know where the Hurd/kFreeBSD ports are specified
externally, if indeed they are at all.

Review/comments/corrections welcome. I hope this helps with what
you're looking for, Matthias?

Hi Matthias,

Steve McIntyre wrote:

I think the Multiarch/Tuples wiki page is now in a sane state, though
as always it could presumably be improved even more.  I think future
required improvements can be tracked separately.  Do you mind if this
bug is closed?

Thanks much,
Jonathan

severity 664257 important
thanks

lowered the severity. IMO it should stay open until multiarch is incorporated
into the FHS and/or the LSB.

  Matthias

Matthias Klose writes ("Bug#664257: multiarch tuples are not documented/defined"):

We do not normally keep a bug open in the Debian BTS that cannot be
fixed in Debian.

What change to the Debian operating system, or to processes,
documents, infrastructure or organisational arrangements, maintained
by the Debian project, is this bug requesting ?

Ian.

I won't fight for this. But it's some kind of Debian responsibility to
address/forward these.  Just filing this with the FHS and/or LSB is likely
getting ignored.  If you have better ways to track progress with this issue,
please tell here.

]] Matthias Klose

JFTR, the FHS and the LSB has a bug tracker, so while filing those might
does not guarantee they'll be fixed, it won't just get dropped on the
floor either.

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

Aren't the Upstream and Forwarded tags exactly for this situation?

MfG
        Goswin

Goswin von Brederlow writes ("Re: Bug#664257: multiarch tuples are not documented/defined"):
...

No.

Upstream means that we agree that the problem is a bug in Debian, but
that the bug is also in the upstream code - ie, we have inherited it
from upstream.

Forwarded means that we agree that the problem is a bug in Debian; we
think that the best way to fix it is to engage with upstream (and
perhaps take their fix in due course, or perhaps cherry pick it); and
we have therefore notified upstream via their bug tracker.

These overlap.  Normally Forwarded would imply Upstream although I
guess there might be bizarre situations where we would (for example)
ask for upstream help or advice with fixing a bug which manifests only
in Debian.

But neither of them is appropriate if the bug cannot be fixed by any
change in Debian (a package, process, document, or whatever).

Ian.

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
in Debian.

The bug is also in the upstream code since upstream does not document
the tuples and we inherited that from them.

So the bug should be reported in upstreams BTS and then tagged as
forwarded. Once they add the multiarch tuples we can cherry pick that or
wait for the next release. That all seems to fit perfectly with your
description.

Ok, we also created the problem by inventing the multiarch tuples. But
still, we want upstream to fix this and don't want to diverge from
them.

I don't agree with that. Where does it say that and how is that usefull?

For one thing a bug can always be fixed in Debian wth enough work if it
is fixable at all. It just might not be the right thing to do. For
example the multiarch tuples could be added to Debian policy with the
proper exceptions to the FHS and so on.

MfG
        Goswin

reassign 664257 debian-policy 3.9.3.1
affects 664257 =
tags 664257 = upstream
quit

Goswin von Brederlow wrote:

Fine, reassigning to policy.

Never say I didn't do anything for you... :)

Policy maintainers, see http://wiki.debian.org/Multiarch/Tuples for a
nice table to incorporate.  Ultimately we would like to see this,
along with some more text to make it precise, in some LSB document
such as the FHS.

Thanks for your work, and hope that helps,
Jonathan

Goswin von Brederlow writes ("Re: Bug#664257: multiarch tuples are not documented/defined"):

They are now documented on the wiki, as previously noted in this
thread.

I'm not sure exactly what you mean.  In which upstream package,
shipped by Debian, do you think this documentation should be ?
Are you saying that this bug report should now be regarded as a
request to move the documentation from the wiki to some source
package ?

Should I file a bug in the Debian BTS about the fact that my
employer's Microsoft Exchange server corrupts emails ?

I really don't see the difference, in principle ...

To be honest what I mostly seem to understand from your contributions
to this bug a general but rather unfocused hostility to multiarch.  It
is of course fine for you not to like multiarch.  But the purpose of
the BTS is not to be an outlet for gripes; if it were I have plenty of
my own.  The purpose of the BTS is for us to track specific problems,
the correction of which lies in our power.

But I'm wasting too much of everyone's time arguing about the state of
this now-non-bug.  It would be better just to let it sit and rot in
the BTS so this will be my last message here.

Ian.

Trimming the cc list down to something somewhat less large.

Jonathan Nieder <jrnieder@gmail.com> writes:
for LSB to incorporate something.  If this table should go into Debian
Policy (which at first glance seems like a reasonable idea), then that
will be the criteria for closing the bug.  If people want to bring this
forward with LSB, a bug against debian-policy is not the mechanism for
doing that.

Hi Russ et al,

The patch below documents the Architecture field.  It doesn't cover
architecture tuples yet, but presumably once the description of
architectures is in good shape it would not be hard to add a mapping
from Debian arches to pathnames to section 9.1.5.

Some concerns:

 - what should the normative content be?  It would not be too strange
   to put a firmware file that happens to be a MIPS binary in an
   "Architecture: i386" or "Architecture: all" package, and I think
   it is important to keep permitting that.

   How should this be worded to permit that sort of thing while still
   making it clear that a package installing MIPS DSOs as NSS plugins
   under /usr/lib/nss ought to use architecture: mips or mipsel?

 - what happens if an ABI document is just wrong?  (For example, I
   have no idea whether the m68k psABI is accurate.)

 - the notion of ABI in the multiarch sense is surprisingly
   slippery.  Corrections and clarifications to the definition used
   below could be useful --- the important notion of "which objects
   can share a process image?" didn't manage to find its way in.

 - is it okay to rely so heavily on external resources?  Is it safe to
   assume that the reader can look up link targets when needed, or
   does link text need to be unambiguous?  Would we need to include a
   summary or copy of some of the cited standards in case they
   disappear?

I didn't include the full table from [1], though it might make a nice
appendix.  If the text is working as it ought to, then it should be
possible to infer the omitted values (endianness, sizeof(long), and so
on) from the descriptions below.

My hope is that this documentation might make it easier to explain the
purpose and semantics of the Multiarch: field later.

Improvements welcome, of course.  What do you think?

[1] http://wiki.debian.org/Multiarch/Tuples

 policy.sgml |  192 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 191 insertions(+), 1 deletion(-)

diff --git a/policy.sgml b/policy.sgml
index 52dbb26a..1a7ed748 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -1423,6 +1423,25 @@

       </sect>

+      <sect id="architecture">
+	<heading>Architecture</heading>
+
+	<p>
+	  Every Debian binary package must have an <tt>Architecture</tt>
+	  control field which describes the ABI used by dynamically-linked
+	  binaries and public shared libraries in the package and
+	  packages it interacts with.  For example, packages built to run
+	  on a 32-bit Intel-architecture GNU/Linux system would use an
+	  <tt>Architecture</tt> of <tt>i386</tt>.
+	</p>
+
+	<p>
+	  Unless otherwise specified, dependencies specified using the
+	  <tt>Suggests</tt>, <tt>Depends</tt>, <tt>Recommends</tt>, and
+	  <tt>Pre-Depends</tt> fields refer to packages of the same
+	  architecture.
+	</p>
+      </sect>
     </chapt>


@@ -2945,7 +2964,7 @@ Package: libc6
 	    <list>
 		<item>
 		  A unique single word identifying a Debian machine
-		  architecture as described in <ref id="arch-spec">.
+		  architecture as described in <ref id="arch-short-name">.
 		</item>
 		<item>
 		  An architecture wildcard identifying a set of Debian
@@ -3052,6 +3071,177 @@ Package: libc6
 	    See <ref id="debianrules"> for information on how to get
 	    the architecture for the build process.
 	  </p>
+
+	  <sect2 id="arch-short-name">
+	    <heading>Debian architecture names</heading>
+
+	    <p>
+	      Binary programs and public shared libraries in binary
+	      packages must use the appropriate binary format,
+	      basic operating system interface, and procedure linkage
+	      convention declared in the <tt>Architecture</tt> field.
+	      <footnote>
+		The <tt>Architecture</tt> field indicates the system
+		ABI but not the precise instruction set or system
+		libraries used: the former is generally determined by
+		convention with exceptions noted in the package
+		description or using hwcap paths, and the latter
+		expressed using package dependencies.
+	      </footnote>
+	    </p>
+
+	    <p>
+	      <taglist>
+		<tag><tt>alpha</tt></tag>
+		<item>
+		  GNU/Linux,
+		  <url id="http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/V51A_HTML/ARH9MBTE/TITLE.HTM"
+		    name="Tru64 5.1 Calling Standard for Alpha Systems">
+		</item>
+
+		<tag><tt>arm</tt></tag>
+		<item>
+		  GNU/Linux, little endian,
+		  <url id="http://infocenter.arm.com/help/topic/com.arm.doc.dui0041c/BGBGFIDA.html"
+		    name="ARM Procedure Call Standard (obsolete)">
+		</item>
+
+		<tag><tt>armel</tt></tag>
+		<item>
+		  GNU/Linux, little endian,
+		  <url id="https://sourcery.mentor.com/GNUToolchain/kbentry39"
+		    name="ARM GNU/Linux ABI 1.0">
+		</item>
+
+		<tag><tt>armhf</tt></tag>
+		<item>
+		  GNU/Linux, little endian,
+		  <url id="https://sourcery.mentor.com/GNUToolchain/kbentry39"
+		    name="ARM GNU/Linux ABI 1.0">,
+		  except that function calls use VFP Register Arguments
+		  as described in the
+		  <url id="http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042a/IHI0042A_aapcs.pdf"
+		    name="Procedure Call Standard for the ARM Architecture">,
+		  section 6.
+		</item>
+
+		<tag><tt>hppa</tt></tag>
+		<item>
+		  <url id="http://wiki.parisc-linux.org/ToolChain"
+		    name="PA-RISC Linux 32-bit ELF">
+		</item>
+
+		<tag><tt>hurd-i386</tt></tag>
+		<item>
+		  GNU/Hurd,
+		  <url id="http://refspecs.linuxbase.org/elf/abi386-4.pdf"
+		    name="Intel IA-32 psABI">,
+		  16-byte stack alignment
+		</item>
+
+		<tag><tt>kfreebsd-i386</tt></tag>
+		<item>
+		  GNU/kernel of FreeBSD,
+		  <url id="http://refspecs.linuxbase.org/elf/abi386-4.pdf"
+		    name="Intel IA-32 psABI">,
+		  16-byte stack alignment
+		</item>
+
+		<tag><tt>i386</tt></tag>
+		<item>
+		  <url id="http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-IA32/LSB-Core-IA32/elf-ia32.html"
+		    name="LSB IA32 4.1">,
+		  16-byte stack alignment
+		</item>
+
+		<tag><tt>ia64</tt></tag>
+		<item>
+		  <url id="http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-IA64/LSB-Core-IA64/elf-ia64.html"
+		    name="LSB IA64 4.1">
+		</item>
+
+		<tag><tt>m68k</tt></tag>
+		<item>
+		  GNU/Linux, Motorola 68000 psABI (ISBN 978-0138776633)
+		</item>
+
+		<tag><tt>mips</tt></tag>
+		<item>
+		  GNU/Linux, big endian,
+		  <url id="http://refspecs.linuxbase.org/elf/mipsabi.pdf"
+		    name="MIPS o32 ABI">
+		</item>
+
+		<tag><tt>mipsel</tt></tag>
+		<item>
+		  GNU/Linux, little endian,
+		  <url id="http://refspecs.linuxbase.org/elf/mipsabi.pdf"
+		    name="MIPS o32 ABI">
+		</item>
+
+		<tag><tt>powerpc</tt></tag>
+		<item>
+		  <url id="http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-PPC32/LSB-Core-PPC32/elf-ppc32.html"
+		    name="LSB PPC32 4.1">
+		</item>
+
+		<tag><tt>powerpcspe</tt></tag>
+		<item>
+		  <url id="http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-PPC32/LSB-Core-PPC32/elf-ppc32.html"
+		    name="LSB PPC32 4.1">,
+		  except that function calls and relocations use the e500
+		  convention described in the ATR-SPE portion of the
+		  <url id="https://www.power.org/resources/downloads/Power-Arch-32-bit-ABI-supp-1.0.tgz"
+		    name="Power Architecture 32-bit ABI Supplement 1.0">
+		</item>
+
+		<tag><tt>ppc64</tt></tag>
+		<item>
+		  <url id="http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-PPC64/LSB-Core-PPC64/elf-ppc64.html"
+		    name="LSB PPC64 4.1">
+		</item>
+
+		<tag><tt>s390</tt></tag>
+		<item>
+		  <url id="http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-S390/LSB-Core-S390/elf-s390.html"
+		    name="LSB S390 4.1">
+		</item>
+
+		<tag><tt>s390x</tt></tag>
+		<item>
+		  <url id="http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-S390X/LSB-Core-S390X/elf-s390x.html"
+		    name="LSB S390X 4.1">
+		</item>
+
+		<tag><tt>sparc</tt></tag>
+		<item>
+		GNU/Linux,
+		  <url id="http://www.sparc.com/standards/psABI3rd.pdf"
+		    name="32-bit SPARC psABI">
+		</item>
+
+		<tag><tt>sparc64</tt></tag>
+		<item>
+		  GNU/Linux,
+		  <url id="http://www.sparc.com/standards/64.psabi.1.35.ps.Z"
+		    name="64-bit SPARCv9 psABI">
+		</item>
+
+		<tag><tt>kfreebsd-amd64</tt></tag>
+		<item>
+		  GNU/kernel of FreeBSD,
+		  <url id="http://x86-64.org/documentation/abi.pdf"
+		    name="AMD64 psABI">
+		</item>
+
+		<tag><tt>amd64</tt></tag>
+		<item>
+		  <url id="http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-AMD64/LSB-Core-AMD64/elf-amd64.html"
+		    name="LSB AMD64 4.1">
+		</item>
+	      </taglist>
+	    </p>
+	  </sect2>
 	</sect1>

 	<sect1 id="f-Essential">

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

Yes, like Jonathan wrote:

Jonathan Nieder <jrnieder@gmail.com> writes:

I was more thinking along the line of forwarded, as in filing it in the
upstream BTS someone mentioned before and getting in touch with the FHS
people and convince them to add them. Obviously just setting the tag
alone is not doing anything to resolve the issue.

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

The difference is that Debian does not contain Microsoft Exchange but it
does contain the FHS and other LSB stuff.

He said to the person advocating multiarch for the last 6 years.

Clearly I'm not the person to convince others to add multiarch tupples
to their specs. So someone with decent debating skills please pick up
this issue and get in contact with the FHS/LSB people.

MfG
        Goswin

Goswin von Brederlow wrote:

I don't see why or why not.  But it isn't really about convincing ---
I'd be hard pressed to find someone who _doesn't_ want this stuff
documented better.

First, thanks Jonathan a lot for providing this patch. While this is
not the full story this gives us a better basis to document multiarch.

Another similar case are binaries optimised for a sub architecture.
(e.g. SSE2 optimised libraries).

For most practical purpose, the exact ABI is decided by the C compiler.
Thus we can expect gcc/clang upstream to deal with that.

Again, for most practical purpose, what matter is to be able to match the compiler
documentation with Debian documentation. If the compiler documentations states
that ABI=foo target "LSB IA64 4.1" and the Debian document says to target
"LSB IA64 4.1", then the developer know this is the right option without having
to read the ABI document.

I am very tempted to merge your patch except for the first paragraph:

Some words about architecture-independent packages are in order.

But outside that, is there objections to merging this patch ?
Seconds ?

Cheers,

First, thanks Jonathan a lot for providing this patch. While this is
not the full story this gives us a better basis to document multiarch.

Another similar case are binaries optimised for a sub architecture.
(e.g. SSE2 optimised libraries).

For most practical purpose, the exact ABI is decided by the C compiler.
Thus we can expect gcc/clang upstream to deal with that.

Again, for most practical purpose, what matter is to be able to match the compiler
documentation with Debian documentation. If the compiler documentations states
that ABI=foo target "LSB IA64 4.1" and the Debian document says to target
"LSB IA64 4.1", then the developer know this is the right option without having
to read the ABI document.

I am very tempted to merge your patch except for the first paragraph:

Some words about architecture-independent packages are in order.

But outside that, is there objections to merging this patch ?
Seconds ?

Cheers,

Hello all,

Here a slightly modified version of Jonathan patch that mention Architecture:all
packages.

Please comment or second it. I would like to commit it soon as a start to
multiarch documentation in policy.

Cheers,

Hello all,

Here a slightly modified version of Jonathan patch that mention Architecture:all
packages.

Please comment or second it. I would like to commit it soon as a start to
multiarch documentation in policy.

Cheers,

Independently of this bug report, I think moving part of the multiarch
specification from the wiki to the policy is a good idea.

Cheers,

Bill Allombert <ballombe@debian.org> writes:

[...]

Seconded, although I suggest sorting the taglist alphabetically when
applying.

Bill Allombert <ballombe@debian.org> writes:

[...]

Seconded, although I suggest sorting the taglist alphabetically when
applying.

Hi all,

it is at least second time as we needed to have a discussion about
tool-chains for Xtensa based devices (for firmware-ath9k-htc and for
esp8266). With the time we will get probably more discussions for
similar platforms.
Since there is no official or documented statement or naming schema for
debian, it will be good if we can start to work in the right direction.

The problematic of this platform can be described as follow:
"The Xtensa processor architecture is a configurable and extensible
synthesizable 32-bit RISC processor core. SoC and processor designers
can select from a variety of options, such as instruction-set extensions
(for example, narrow instructions, floating point instructions, etc.),
memory, cache, and interrupt configurations. Moreover, Xtensa processors
also support custom-defined instructions and registers. Nevertheless,
all Xtensa processors share a common base instruction set architecture,
thereby ensuring compatibility of third party application software and
development tools."
See http://wiki.linux-xtensa.org/index.php/Supported_Processors

As you can see, there are number of devices or configuration able to run
linux on Xtensa:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/xtensa/configs?h=v4.20

It means, this discussion related not only to bare-metal configurations.

So far, binutils and GCC do not support a usual way to dynamically
configure for some specific platform. Usually "configuration" is
distributed as set of patches against binutils and gcc with related
project. It means, there is no way to provide a tool-chain which is able
to cover all configurations.

There is a project to provide a way to use architecture related
configurations as a plugin against binutils or gcc:
https://github.com/jcmvbkbc/xtensa-dynconfig

Even if we will move to xtensa-dynconfig, we should use normalized names
for plugins.

By analyzing different xtensa toolchain patches I made following
assumptions:
- all Xtensa architectures designed as customizable, but not all vendors
customize it.
- code build for some base version of Xtensa, will always run on the
custom version of this architecture but not other way around.

Based on this assumptions and experience with MIPS names I would suggest
following naming schema:
<arch_main_name><arch_variant><vendor_customization>

arch_main_name - usually xtensa
arch_variant - for example lx2, or 106micro
vendor_customization - it is hard to get any description from vendor, so
i would suggest to use one of chip names used with this customization.
In case of Atheros devices, we have same CPU variant for ar9271 and
ar7010, may be other controller use same variant as well. Since ar9271
is more popular, using this chipname should be enough.

Atheros ar9271 is using Xtensa LX2.1.0, so the name would probably be:
xtensa-lx2.1.0-ar9271
or
xtensalx2.1.0ar9271

esp8266 seems to use Xtensa Diamond 106Micro, so the name would be:
xtensa-d106micro-esp8266
or
xtensad106microesp8266

As reference I redirect initial discussion for binutils-xtensa-lx106.

Am 29.12.18 um 19:37 schrieb Jonathan McDowell:

My reasoning is following:
Xtensa is undocumented mess of assumptions and esoteric believes. This
discussion showed it just one more time. If some one will seek how to
support next chip running Xtensa, this person should start from scratch.
Even if it is plain unchanged platform provided by Tensilica/Cadence.
With nearly no help from any company to identify and sort things we
spread our man power to support in some case just same architecture or
variant.

I've got attention to this issue, only because it may cover architecture
of other package. After some investigation, I can say - no, it is not.
Alone the time needed to investigate what architecture it is and is it
similar with other arch, is an indicator for huge issues in this case.

For the archive, here is short summary for some of know chips using
Xtensa https://wikidevi.com/wiki/Xtensa, hope it will save time for some
one.

As independent review for this package i would suggest:
- please clean binutils-xtensa-lx106/debian/overlay. Convert it from dos
to unix formatting and create a diff against mainline projects. It will
help to see what was actually changed.
- please change the package name.
searching for existing accepted binutils for not linux will give:
binutils-arm-none-eabi
binutils-avr
binutils-h8300-hms
binutils-i686-gnu
binutils-i686-kfreebsd-gnu
binutils-m68hc1x
binutils-mingw-w64
binutils-mingw-w64-i686
binutils-mingw-w64-x86-64
binutils-msp430
binutils-x86-64-kfreebsd-gnu
binutils-z80

In most cases we use chip name or architecture. binutils-xtensa-lx106 is
confusing, lx106 is not official xtensa platform, not official chip name
and even not architecture specified in esp8266 documentation. It seems
to be some kind of tradition.

Since MIPS seems to have long list of architecture variants, similar
rule should be applied for Xtensa:
binutils-mips-linux-gnu
binutils-mips64-linux-gnuabi64
binutils-mips64-linux-gnuabin32
binutils-mips64el-linux-gnuabi64
binutils-mips64el-linux-gnuabin32
binutils-mipsel-linux-gnu
binutils-mipsisa32r6-linux-gnu
binutils-mipsisa32r6el-linux-gnu
binutils-mipsisa64r6-linux-gnuabi64
binutils-mipsisa64r6-linux-gnuabin32
binutils-mipsisa64r6el-linux-gnuabi64
binutils-mipsisa64r6el-linux-gnuabin32

It can be: bintuils-xtensa106mesp8266 or
bintuils-xtensa106micro-esp8266, which will be translated as "ESP8266
specific architecture based on Xtensa 106Micro"
Some one who will seek for all utils for 106micro should be able to find it.
- I would recommend to clarify real CPU architecture with Espressif or
Cadence. In case it is a plain Xtensa Diamond 106Micro architecture,
most of name related issues will be solved and this package will be
clearly interesting for other users.