This is the mail archive of the
mailing list for the GCC project.
Re: Selecting an architecture tuple for the Rumprun toolchain
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Martin Lucina <martin at lucina dot net>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Thu, 9 Apr 2015 16:20:03 +0000
- Subject: Re: Selecting an architecture tuple for the Rumprun toolchain
- Authentication-results: sourceware.org; auth=none
- References: <20150330142356 dot GE7411 at nodbug dot moloch dot sk> <alpine dot DEB dot 2 dot 10 dot 1504021610540 dot 27469 at digraph dot polyomino dot org dot uk> <20150409152406 dot GI31753 at nodbug dot moloch dot sk>
On Thu, 9 Apr 2015, Martin Lucina wrote:
> I'm not sure what you mean by "tuples do not distinguish the possible use
> of an emulation environment in which to run code". If by "emulation
A toolchain that builds binaries that run for x86_64 GNU/Linux with the
normal glibc port and kernel has target x86_64-*-linux-gnu (or
i?86-*-linux-gnu with -m64 used). That is the case regardless of whether
the actual platform on which the binaries are then run is x86_64
GNU/Linux, or a BSD system which provides support for running unmodified
binaries using Linux syscalls, or QEMU running on AArch64 GNU/Linux doing
the same, etc.
Some tools may also support generating object files that can be linked
into binaries for multiple OSes - for example, ARM EABI tools generating
objects that only use the C library via the CLIBABI portable object
interfaces - in that case the tuple used would typically be for a
bare-metal system (arm-*-eabi) but the objects might be used on many
> > If you would use a different glibc port, would it be meaningful to do so
> > both for Linux (however Linux is involved in your system) and for NetBSD?
> > If so, it seems you have something like (but different from)
> > *-*-linux-gnu, and something like (but different from) *-*-knetbsd-gnu -
> > if both kernels affect the glibc port in some way, the kernel component of
> > the triplet might need to include both kernel names, or else the OS
> > component might need to contain one of them. (I don't recommend treating
> > the vendor component as semantically significant.) Thus, you might have
> > arm-*-linux-gnueabirumprun, or (if multiple rumprun variants each need
> > their own tools / libc) arm-*-linux-gnueabirumprunxen.
> The last variant in the above paragraph is what we need to distinguish all
> possible tools/libc combinations.
> Why do you not recommend using the vendor component for anything
> significant? To me it seems the logical place to say "this is a rumprun
> toolchain", plus the result is easier to parse than putting "rumprun" AND
> "platform" AND "userspace" all in the last component.
The vendor component is typically a company name - used either in cases
where only one name is normally used (*-sun-solaris*, *-hp-hpux*,
*-ibm-aix*, etc.), or, for free software systems, for branding purposes if
at all (*-<company>-linux-gnu*). Presumably multiple distributors might
each distribute rumprun tools, branded for that distributor, so
<cpu>-<company>-linux-gnurumprunxen or <cpu>-<company>-netbsd-rumprunxen
Joseph S. Myers