The Clang Universal Driver Project
Clang is inherently a cross compiler, in that it is always capable of
building code for targets which are a different architecture or even operating
system from the one running the compiler. However, actually cross compiling in
practice involves much more than just generating the right assembly code for a
target, it also requires having an appropriate tool chain (assemblers, linkers),
access to header files and libraries for the target, and many other details (for
example, the calling convention or whether software floating point is in
use). Traditionally, compilers and development environments provide little
assistance with this process, so users do not have easy access to the powerful
underlying cross-compilation abilities of clang.
We would like to solve this problem by defining a new model for how cross
compilation is done, based on the idea of a universal driver. The key
point of this model is that the user would always access the compiler through a
single entry point (e.g., /usr/bin/cc) and provide an argument
specifying the configuration they would like to target. Under the hood
this entry point (the universal driver) would have access to all the information
that the driver, compiler, and other tools need to build applications for that
target.
This is a large and open-ended project. It's eventual success depends not
just on implementing the model, but also on getting buy-in from compiler
developers, operating system distribution vendors and the development community
at large. Our plan is to begin by defining a clear list of the problems we want
to solve and a proposed implementation (from the user perspective).
This project is in the very early (i.e., thought experiment) stages of
development. Stay tuned for more information, and of course, patches
welcome!
See also PR4127.
Existing Solutions and Related Work
- gcc's command line arguments -V, -B, -b are
generic but limited solutions to related problems. Similarly, -m32
and -m64 solve a small subset of the problem for specific
architectures.
- gcc's multilibs
solve the part of the problem that relates to finding appropriate libraries
and include files based on particular feature support (soft float,
etc.).
- Apple's "driver driver" supported by gcc and clang solve a subset of the
problem by supporting -arch. Apple also provides a tool chain which
supports universal
binaries and object files which may include data for multiple
architectures. See TN2137
for an example of how this is used.
- Many operating systems and environments solve the problem by installing
complete development environments (including the IDE, tools, header files,
and libraries) for a single tool chain. This is cumbersome for users and
does not match well with tools which are inherently capable of cross
compiling.
- The Debian ArmEabiPort
wiki page for their work to support the ARM EABI provide an interesting
glimpse into how related issues impact the operating system distribution.
- FatELF is a proposal for bringing
Mac OS X like "Universal Binary" support to ELF based platforms.
@
1.1.1.1
log
@Import Clang 3.4rc1 r195771.
@
text
@@
1.1.1.1.30.1
log
@Mostly merge changes from HEAD upto 20200411
@
text
@@
1.1.1.2
log
@Mark old LLVM instance as dead.
@
text
@@
1.1.1.1.8.1
log
@file UniversalDriver.html was added on branch tls-maxphys on 2014-08-19 23:49:29 +0000
@
text
@d1 87
@
1.1.1.1.8.2
log
@Rebase to HEAD as of a few days ago.
@
text
@a0 87
The Clang Universal Driver Project
Clang is inherently a cross compiler, in that it is always capable of
building code for targets which are a different architecture or even operating
system from the one running the compiler. However, actually cross compiling in
practice involves much more than just generating the right assembly code for a
target, it also requires having an appropriate tool chain (assemblers, linkers),
access to header files and libraries for the target, and many other details (for
example, the calling convention or whether software floating point is in
use). Traditionally, compilers and development environments provide little
assistance with this process, so users do not have easy access to the powerful
underlying cross-compilation abilities of clang.
We would like to solve this problem by defining a new model for how cross
compilation is done, based on the idea of a universal driver. The key
point of this model is that the user would always access the compiler through a
single entry point (e.g., /usr/bin/cc) and provide an argument
specifying the configuration they would like to target. Under the hood
this entry point (the universal driver) would have access to all the information
that the driver, compiler, and other tools need to build applications for that
target.
This is a large and open-ended project. It's eventual success depends not
just on implementing the model, but also on getting buy-in from compiler
developers, operating system distribution vendors and the development community
at large. Our plan is to begin by defining a clear list of the problems we want
to solve and a proposed implementation (from the user perspective).
This project is in the very early (i.e., thought experiment) stages of
development. Stay tuned for more information, and of course, patches
welcome!
See also PR4127.
Existing Solutions and Related Work
- gcc's command line arguments -V, -B, -b are
generic but limited solutions to related problems. Similarly, -m32
and -m64 solve a small subset of the problem for specific
architectures.
- gcc's multilibs
solve the part of the problem that relates to finding appropriate libraries
and include files based on particular feature support (soft float,
etc.).
- Apple's "driver driver" supported by gcc and clang solve a subset of the
problem by supporting -arch. Apple also provides a tool chain which
supports universal
binaries and object files which may include data for multiple
architectures. See TN2137
for an example of how this is used.
- Many operating systems and environments solve the problem by installing
complete development environments (including the IDE, tools, header files,
and libraries) for a single tool chain. This is cumbersome for users and
does not match well with tools which are inherently capable of cross
compiling.
- The Debian ArmEabiPort
wiki page for their work to support the ARM EABI provide an interesting
glimpse into how related issues impact the operating system distribution.
- FatELF is a proposal for bringing
Mac OS X like "Universal Binary" support to ELF based platforms.
@
1.1.1.1.4.1
log
@file UniversalDriver.html was added on branch yamt-pagecache on 2014-05-22 16:19:50 +0000
@
text
@d1 87
@
1.1.1.1.4.2
log
@sync with head.
for a reference, the tree before this commit was tagged
as yamt-pagecache-tag8.
this commit was splitted into small chunks to avoid
a limitation of cvs. ("Protocol error: too many arguments")
@
text
@a0 87
The Clang Universal Driver Project
Clang is inherently a cross compiler, in that it is always capable of
building code for targets which are a different architecture or even operating
system from the one running the compiler. However, actually cross compiling in
practice involves much more than just generating the right assembly code for a
target, it also requires having an appropriate tool chain (assemblers, linkers),
access to header files and libraries for the target, and many other details (for
example, the calling convention or whether software floating point is in
use). Traditionally, compilers and development environments provide little
assistance with this process, so users do not have easy access to the powerful
underlying cross-compilation abilities of clang.
We would like to solve this problem by defining a new model for how cross
compilation is done, based on the idea of a universal driver. The key
point of this model is that the user would always access the compiler through a
single entry point (e.g., /usr/bin/cc) and provide an argument
specifying the configuration they would like to target. Under the hood
this entry point (the universal driver) would have access to all the information
that the driver, compiler, and other tools need to build applications for that
target.
This is a large and open-ended project. It's eventual success depends not
just on implementing the model, but also on getting buy-in from compiler
developers, operating system distribution vendors and the development community
at large. Our plan is to begin by defining a clear list of the problems we want
to solve and a proposed implementation (from the user perspective).
This project is in the very early (i.e., thought experiment) stages of
development. Stay tuned for more information, and of course, patches
welcome!
See also PR4127.
Existing Solutions and Related Work
- gcc's command line arguments -V, -B, -b are
generic but limited solutions to related problems. Similarly, -m32
and -m64 solve a small subset of the problem for specific
architectures.
- gcc's multilibs
solve the part of the problem that relates to finding appropriate libraries
and include files based on particular feature support (soft float,
etc.).
- Apple's "driver driver" supported by gcc and clang solve a subset of the
problem by supporting -arch. Apple also provides a tool chain which
supports universal
binaries and object files which may include data for multiple
architectures. See TN2137
for an example of how this is used.
- Many operating systems and environments solve the problem by installing
complete development environments (including the IDE, tools, header files,
and libraries) for a single tool chain. This is cumbersome for users and
does not match well with tools which are inherently capable of cross
compiling.
- The Debian ArmEabiPort
wiki page for their work to support the ARM EABI provide an interesting
glimpse into how related issues impact the operating system distribution.
- FatELF is a proposal for bringing
Mac OS X like "Universal Binary" support to ELF based platforms.
@