Target Triplet: Difference between revisions

From OSDev.wiki
Jump to navigation Jump to search
[unchecked revision][unchecked revision]
Content added Content deleted
(Created page with "Host Triplets describe a platform on which code runs and are a core concept in the GNU build system. They contain three fields: the name of the CPU family/model, the vendor, a...")
 
m (Bot: Replace deprecated source tag with syntaxhighlight)
 
(8 intermediate revisions by 4 users not shown)
Line 1: Line 1:
Host Triplets describe a platform on which code runs and are a core concept in the GNU build system. They contain three fields: the name of the CPU family/model, the vendor, and the operating system name.
Target Triplets describe a platform on which code runs and are a core concept in the GNU build system. They contain three fields: the name of the CPU family/model, the vendor, and the operating system name. You can view the unambiguous target triplet for your current system by running:

<syntaxhighlight lang="bash">
gcc -dumpmachine
</syntaxhighlight>


== Structure ==
== Structure ==


Host triplets have this simple structure:
Target triplets have this simple structure:


machine-vendor-operatingsystem
machine-vendor-operatingsystem
Line 11: Line 15:
x86_64-unknown-freebsd
x86_64-unknown-freebsd


Notice how the vendor field is mostly irrelevant and is usually '<tt>pc</tt>' for 32-bit x86 systems or '<tt>unknown</tt>' or '<tt>none</tt>' for other systems. The simple three-field host triplet we have seen so far is unambiguous and easy to parse. However, since the vendor field is mostly unused, the GNU build system allows you to leave out the vendor field; the build system will automatically insert a default vendor part when it disambiguates your host triplet. For instance, this allows you to type:
Notice how the vendor field is mostly irrelevant and is usually '<tt>pc</tt>' for 32-bit x86 systems or '<tt>unknown</tt>' or '<tt>none</tt>' for other systems. The simple three-field target triplet we have seen so far is unambiguous and easy to parse. However, since the vendor field is mostly unused, the GNU build system allows you to leave out the vendor field; the build system will automatically insert a default vendor part when it disambiguates your target triplet. For instance, this allows you to type:


x86_64-freebsd
x86_64-freebsd


The build system will then automatically deduce that the vendor is the default (<tt>unknown</tt>) if it wishes to know the unambiguous host triplet. Note that parsing host triplets are a bit more tricky, as sometimes the operating system field can be two fields:
The build system will then automatically deduce that the vendor is the default (<tt>unknown</tt>) if it wishes to know the unambiguous target triplet. Note that parsing target triplets are a bit more tricky, as sometimes the operating system field can be two fields:


x86_64-unknown-linux-gnu
x86_64-unknown-linux-gnu
Line 23: Line 27:
x86_64-linux-gnu
x86_64-linux-gnu


This is most definitely ambiguous. Most autoconf-based packages ship with a huge shell script called <tt>config.sub</tt> whose function is to disambiguate host triplet using a long list of known CPUs and known operating systems.
This is most definitely ambiguous. Most autoconf-based packages ship with a huge shell script called <tt>config.sub</tt> whose function is to disambiguate target triplet using a long list of known CPUs and known operating systems.


== Rationale ==
== Rationale ==


Host triplets are intended to be systematic unambiguous platform names (well, after disambiguation). They lets build systems understand exactly which system the code will run on and allows enabling platform-specific features automatically. In any compilation setting, there are usually three platforms involved (which might be the same three ones):
Target triplets are intended to be systematic unambiguous platform names (well, after disambiguation). They lets build systems understand exactly which system the code will run on and allows enabling platform-specific features automatically. In any compilation setting, there are usually three platforms involved (which might be the same three ones):


* '''Build Platform''': This is the platform on which the compilation tools are executed.
* '''Build Platform''': This is the platform on which the compilation tools are executed.
Line 33: Line 37:
* '''Target Platform''': If this is a compiler, this is the platform that the compiler will generate code for.
* '''Target Platform''': If this is a compiler, this is the platform that the compiler will generate code for.


This means that up to three differently-targeted compilers might be in play (if you are building a GCC on platform A, which will run on platform B, which produces executables for platform C). This problem is solved by simply prefixing the compilation tools with the host triplet. When you build a cross-compiler, the installed executables will be prefixed with the specified target triplet:
This means that up to three differently-targeted compilers might be in play (if you are building a GCC on platform A, which will run on platform B, which produces executables for platform C). This problem is solved by simply prefixing the compilation tools with the target triplet. When you build a cross-compiler, the installed executables will be prefixed with the specified target triplet:


i586-elf-gcc
i686-elf-gcc


This prevents the wrong compiler from being used (and prevents things from the build machine to leak onto the host machine) if build systems are carefully to prefix all compilation tools with the host prefix.
This prevents the wrong compiler from being used (and prevents things from the build machine to leak onto the target machine) if build systems are carefully to prefix all compilation tools with the target prefix.


== Host Triplets for Operating Systems Development ==
== Target Triplets for Operating Systems Development ==


For instance, if you develop your own operating system and [[OS Specific Toolchain|modify GCC to add a new host triplet]], yours could be:
For instance, if you develop your own operating system and [[OS Specific Toolchain|modify GCC to add a new target triplet]], yours could be:


x86_64-myos
x86_64-myos
Line 47: Line 51:
However, when starting out you simply wish to use the generic targets that are well-suited for early OS development:
However, when starting out you simply wish to use the generic targets that are well-suited for early OS development:


i586-elf
i686-elf
x86_64-elf
x86_64-elf
arm-none-eabi
arm-none-eabi
aarch64-none-elf
riscv64-none-elf


These are bare targets meant for freestanding programs (bootloaders and kernels) that don't have a user-space.
These are bare targets meant for freestanding programs (bootloaders and kernels) that don't have a user-space.

Latest revision as of 04:44, 9 June 2024

Target Triplets describe a platform on which code runs and are a core concept in the GNU build system. They contain three fields: the name of the CPU family/model, the vendor, and the operating system name. You can view the unambiguous target triplet for your current system by running:

gcc -dumpmachine

Structure

Target triplets have this simple structure:

machine-vendor-operatingsystem

For instance, a FreeBSD system could be written as:

x86_64-unknown-freebsd

Notice how the vendor field is mostly irrelevant and is usually 'pc' for 32-bit x86 systems or 'unknown' or 'none' for other systems. The simple three-field target triplet we have seen so far is unambiguous and easy to parse. However, since the vendor field is mostly unused, the GNU build system allows you to leave out the vendor field; the build system will automatically insert a default vendor part when it disambiguates your target triplet. For instance, this allows you to type:

x86_64-freebsd

The build system will then automatically deduce that the vendor is the default (unknown) if it wishes to know the unambiguous target triplet. Note that parsing target triplets are a bit more tricky, as sometimes the operating system field can be two fields:

x86_64-unknown-linux-gnu

This gets a bit worse since the vendor field can be left out:

x86_64-linux-gnu

This is most definitely ambiguous. Most autoconf-based packages ship with a huge shell script called config.sub whose function is to disambiguate target triplet using a long list of known CPUs and known operating systems.

Rationale

Target triplets are intended to be systematic unambiguous platform names (well, after disambiguation). They lets build systems understand exactly which system the code will run on and allows enabling platform-specific features automatically. In any compilation setting, there are usually three platforms involved (which might be the same three ones):

  • Build Platform: This is the platform on which the compilation tools are executed.
  • Host Platform: This is the platform on which the code will eventually run.
  • Target Platform: If this is a compiler, this is the platform that the compiler will generate code for.

This means that up to three differently-targeted compilers might be in play (if you are building a GCC on platform A, which will run on platform B, which produces executables for platform C). This problem is solved by simply prefixing the compilation tools with the target triplet. When you build a cross-compiler, the installed executables will be prefixed with the specified target triplet:

i686-elf-gcc

This prevents the wrong compiler from being used (and prevents things from the build machine to leak onto the target machine) if build systems are carefully to prefix all compilation tools with the target prefix.

Target Triplets for Operating Systems Development

For instance, if you develop your own operating system and modify GCC to add a new target triplet, yours could be:

x86_64-myos

However, when starting out you simply wish to use the generic targets that are well-suited for early OS development:

i686-elf
x86_64-elf
arm-none-eabi
aarch64-none-elf
riscv64-none-elf

These are bare targets meant for freestanding programs (bootloaders and kernels) that don't have a user-space.