Anonymous user
Meaty Skeleton: Difference between revisions
Jump to navigation
Jump to search
Minot nits to the article prose
| [unchecked revision] | [unchecked revision] |
(Initial pass at cleaning up dependency information) |
(Minot nits to the article prose) |
||
Line 63:
* i686-elf toolchain, as discussed above.
* GRUB, for the grub-mkrescue command, along with the appropriate runtime files.
*
* GNU make 4.0 or later.
* Qemu, optionally for testing the operating system.
This tutorial requires a GNU/Linux system, or a similar enohugh system. The BSD systems may almost work. OS X is not supported but can possibly be made to work with some changes. Windows is not supported, but Windows environments like Cygwin and Windows Subsystem For Linux (WSL) might work.
Line 86 ⟶ 87:
The <tt>/home/bwayne/myos/sysroot</tt> directory acts as a fake root directory for your operating system. This is called a system root, or ''sysroot''.
You can think of the sysroot as the root directory for your operating system. Your build process will build each component of your operating system (kernel, standard library, programs) and gradually install them into the system root. Ultimately the system root will be a fully functional root filesystem for your operating system, you format a partition and copy the files there, add the appropriate configuration files, configure a bootloader to load the kernel from there, and use your harddisk driver and filesystem driver to read the files from there. The system root is thus a temporary directory that will ultimately become the actual root directory of your operating system.
In this example the cross system root is located as <tt>sysroot/</tt>, which is
Line 99 ⟶ 100:
The <tt>-elf</tt> targets have no user-space and are incapable of having one. We configured the compiler with system root support, so it will look in <tt>${SYSROOT}/usr/lib</tt> as expected. We prevented the compiler from searching for a standard library using the --without-headers option when building <tt>i686-elf-gcc</tt>, so it will ''not'' look in <tt>${SYSROOT}/usr/include</tt>. (Once you add a user-space and a libc, you will configure your custom cross-gcc with <tt>--with-sysroot</tt> and it will look in <tt>${SYSROOT}/usr/include</tt>. As a temporary work-around until you get that far, we fix it by passing <tt>-isystem=/usr/include</tt>).
You can change the system root directory layout if you wish, but you will have to modify some Binutils and GCC source code and tell them [[OS Specific Toolchain|what your operating system is]]. This is advanced and not worth doing until you add a proper user-space. Note that the cross-linker currently looks in <tt>/lib</tt>, <tt>/usr/lib</tt> and <tt>/usr/local/lib</tt> by default, so you can move files there without changing Binutils. Also note that we use the <tt>-isystem</tt> option for GCC (as it was configured without a system include directory), so you can move that around freely.
== System Headers ==
Line 107 ⟶ 108:
cross-compile your operating system. This is <tt>useful</tt> as it allows you to
provide the compiler a copy of your headers before you actually compile your
system. You will [[Hosted_GCC_Cross-Compiler#Sysroot_Headers|need to provide the
standard library headers]] when you in the future build a [[Hosted GCC Cross-Compiler]]
Note how your cross-compiler comes with a number of fully freestanding headers
Line 159 ⟶ 161:
The kernel implements the correct way of [[Calling_Global_Constructors|invoking
global constructors]] (useful for C++ code and C code using
<tt>__attribute__((constructor))</tt>. The
which invokes all the global constructors. These are invoked very early in the
boot without any specific ordering. You should only use them to initialize
global variables that could not be initialized at runtime.
The special <tt>__is_kernel</tt> macro lets the source code detect whether
Line 193 ⟶ 194:
The standard headers use a BSD-like scheme where <tt>sys/cdefs.h</tt> declares
a bunch of useful preprocessor macros meant for internal use by the standard
library.
<tt>extern "C" {</tt> and <tt>}</tt> such that C++ code can correctly
link against libc (as libc doesn't use C++ linkage). Note also how the compiler
provides the internal keyword __restrict unconditionally (even in C89) mode,
which is useful for adding the restrict keyword to function prototypes even when
compiling code in pre-C99 or C++ mode.
The special <tt>__is_libc</tt> macro lets the source code detect whether
Line 206 ⟶ 207:
This example comes with a small number of standard functions that serve as
examples and serve to satisfy ABI requirements. Note that the <tt>printf</tt>
function included is very minimal and intentionally doesn't handle most common
features.
== Source Code ==
Line 223 ⟶ 224:
</source>
Check for differences between the git revision used in this article and what you cloned (empty output means there is no difference):
<source lang="bash">
git diff 084d1624bedaa9f9e395f055c6bd99299bd97f58..master
| |||