mirror of
https://github.com/genodelabs/genode.git
synced 2024-12-25 16:31:06 +00:00
68 lines
3.3 KiB
Plaintext
68 lines
3.3 KiB
Plaintext
|
This directory contains patches of the Codezero kernel that are needed for the
|
||
|
|
integration with Genode. Furthermore, some patches address issues with recent
|
||
|
|
tool chains not yet supported by the official Codezero verison.
|
||
|
|
|
||
|
|
:binutils-2.21.patch:
|
||
|
|
|
||
|
|
The GNU assembler of binutils-2.21 complains with an error that was ignored
|
||
|
|
by previous binutils versions:
|
||
|
|
|
||
|
|
"Error: .size expression for ... does not evaluate to a constant"
|
||
|
|
|
||
|
|
This error seems to occur if the argument of 'BEGIN_PROC' does not match
|
||
|
|
the argument of 'END_PROC'. The patch fixes such inconsistencies in the
|
||
|
|
code.
|
||
|
|
|
||
|
|
:gcc_shared_enabled.patch:
|
||
|
|
|
||
|
|
Codezero expect the tool chain to be used for the kernel to not support
|
||
|
|
shared libraries. This is the case for Codesourcery's arm-non-eabi
|
||
|
|
tool chain. Such tool chains use to incorporate both libgcc and libgcc_eh
|
||
|
|
into the single libgcc.a library. In contrast, for tool chains built with
|
||
|
|
'--enable-shared', libgcc does not contain the functions of libgcc_eh. Hence,
|
||
|
|
one symbol called '__aeabi_unwind_cpp_pr0' referenced by libgcc and normally
|
||
|
|
provided by libgcc_eh remains unresolved. There are two possible solutions
|
||
|
|
for this problem: We could link libgcc_eh to the 'final.elf' image as
|
||
|
|
expected by libgcc. However, this way, we will need to implement the
|
||
|
|
the environment expected by libgcc_eh. For Codezero, this is pointless
|
||
|
|
because no C++ is used. The second option is to provide a dummy symbol
|
||
|
|
for '__aeabi_unwind_cpp_pr0' just to make the linker happy. This patch
|
||
|
|
adds such a dummy symbol to 'loader/main.c'.
|
||
|
|
|
||
|
|
:libc_search_dir.patch:
|
||
|
|
|
||
|
|
The userlibs are build with w/o '-nostdinc'. Consequently, the standard
|
||
|
|
search paths of the tool chain are used. Because the user land is
|
||
|
|
normally build with the Codesourcery tool chain 'arm-none-linux-gnueabi',
|
||
|
|
the complete glibc headers (that come with the tool chain) end up in
|
||
|
|
the default search path. Coincidentally, the userlibs SConstruct file
|
||
|
|
misses to supply the Codezero libc headers, which goes undetected because
|
||
|
|
headers such as 'stdio.h' are silently taken from the tool chain's libc.
|
||
|
|
This patch supplies Codezero's libc include-search path for building
|
||
|
|
the userlibs. This enables the userlibs to be built with tool chains
|
||
|
|
that do not come with a complete libc.
|
||
|
|
|
||
|
|
:scons-2.0.1.patch:
|
||
|
|
|
||
|
|
SCons 2.0.1 complains about the 'build_dir' argument being renamed to
|
||
|
|
'variant_dir'. This patch renames the argument where needed for building
|
||
|
|
the kernel and the default container.
|
||
|
|
|
||
|
|
:set_fixed_pager.patch:
|
||
|
|
|
||
|
|
At some point, Codezero abandoned the facility to define the pager for a
|
||
|
|
given thread via the exregs system call. Instead, the kernel hard-wires the
|
||
|
|
creator of the thread as the thread's pager. This is conflicting with
|
||
|
|
Genode's way of creating and paging threads. On the current version of Genode
|
||
|
|
for Codezero, all threads are paged by one thread (thread 3 happens to be the
|
||
|
|
global pager) within core. As a work-around to Codezero's current limitation,
|
||
|
|
we define thread 3 to be the pager of all threads.
|
||
|
|
|
||
|
|
:gcc_4_6_1_fixes.patch:
|
||
|
|
|
||
|
|
Version 4.6.1 of GCC is more picky about dead code than previous versions and
|
||
|
|
warns about unused variables. Because Codezero is build with the '-Werror'
|
||
|
|
flag, these warnings cause the kernel build to fail. The patch fixes those
|
||
|
|
warnings by removing the variables in question.
|
||
|
|
|