How kernel, compiler, and C library work together: Difference between revisions

[unchecked revision][unchecked revision]
Content deleted Content added
Frank (talk | contribs)
Frank (talk | contribs)
m Formating Fixes
Line 9:
==C Library==
 
<blockquote>
''One thing up front: When you begin working on your kernel, ''you
do not have a C library available''. You ''must not <tt>#include</tt>
anything'' you did not write yourself. You will also have to port
an existing C library. See [[GCC Cross-Compiler]], Future Steps /
Standard Library.''
</blockquote>
 
The C library implements the standard C functions (i.e., the things declared in <stdlib.h>, <math.h>, <stdio.h> etc.) and provides them in binary form suitable for linking with user-space applications.
Line 27 ⟶ 29:
And finally, you have [http://www.netlib.org/fdlibm/ fdlibm] and [http://www.fefe.de/dietlibc/ dietlib] that can provide you minimun standard support if you're fine with GPL.
 
<blockquote>
''A more elaborate example of LibraryCalls is available on a different page.''
</blockquote>
 
==Compiler / Assembler==
Line 33 ⟶ 37:
An Assembler takes (plaintext) source code and turns it into (binary) machine code; more precisely, it turns the source into ''object'' code, which contains additional information like symbol names, relocation information etc.
 
A compiler takes higher-level language source code, and either directly turns it into object code, or (as is the case with gccGCC) turns it into Assembler source code and invokes an Assembler for the final step.
 
The resulting object code does ''not'' yet contain any code for standard functions called. If you <tt>include</tt>d e.g. <tt><stdio.h></tt> and used <tt>printf()</tt>, the object code will merely contain a ''reference'' stating that a function named <tt>printf()</tt> (and taking a <tt>const char *</tt> and a number of unnamed arguments as parameters) must be linked to the object code in order to receive a complete executable.
Line 81 ⟶ 85:
==__alloca, ___main==
 
=<tt>alloca()=</tt> is a "semi-standard" C function (from BSD?, but supported by most C implementations) that is used to allocate memory from the stack. On Windows this function is also used for stack probing. As such, =<tt>alloca()=</tt> is referenced in PE binaries, build e.g. by the Cygwin GCC. You can set =<tt>-mno-stack-arg-probe=</tt> to supresssuppress those references.
 
Another "specialityspecialty" of PE binaries is that, if you define =<tt>int main()=</tt>, a function =<tt>void __main()=</tt> is called first thing after entering =<tt>main()=</tt>. You can either define that function, or omit =<tt>main()=</tt> from your kernel code, using a different function as entry point.
 
This explanation of =<tt>alloca()=</tt> comes from Chris Giese, posted to alt.os.dev: %%%
 
<blockquote>
>> I think _alloca() is for stack-probing, which is required by Windows.<br>
 
> What is stack probing?<br>
 
By default, Windows reserves 1 meg of virtual memory for the stack. No page of stack memory is actually allocated (commited) until the page is accessed. This is demand-allocation.
 
The page beyond the top of the stack is the guard page. If this page is accessed, memory will be allocated for it, and the guard page moved downward by 4K (one page). Thus, the stack can grow beyond the initial 1 meg.
 
Windows will not, however, let you grow the stack by accessing discontiguous pages of memory. Going beyond the guard page causes an exception. Stack-probing code prevents this.
</blockquote>
 
Some more information about stack-probing: %%%
-* http://groups.google.com/groups?&selm=702bki%24oki%241%40news.Eindhoven.NL.net
-* http://groups.google.com/groups?&selm=3381B63D.6E39%40austin.finnigan.com
 
 
=<tt>alloca()=</tt> is not just used for stack-probing, but also as a sort of =<tt>malloc()=</tt> -- for dynamically allocating memory for variables/buffers -- without the need to manually free the reserved memory (with =<tt>free()=</tt> as it should be done for =<tt>malloc()=</tt> allocated memory).
 
If you search the man pages for alloca on a UNIX OS you'll find something like this:
Line 111 ⟶ 117:
"_alloca allocates size bytes from the program stack. The allocated space is automatically freed when the calling function exits (not when the allocation merely passes out of scope). Therefore, do not pass the pointer value returned by _alloca as an argument to free."
 
Note that "A stack overflow exception is generated if the space cannot be allocated." so =<tt>alloca()=</tt> might cause the stack to grow.
 
Unfortunately, there are all kinds of caveats with using =<tt>alloca()=</tt>. Notably, Turbo~C/C++ had the limitation that functions calling =<tt>alloca()=</tt> needed to have at least one local variable, and Linux man-page warns the following: %%%
 
<blockquote>
_The''The alloca function is machine and compiler dependent. On many systems its
implementation is buggy. Its use is discouraged._''
</blockquote>
 
<blockquote>
_On''On many systems alloca cannot be used inside the list of arguments of a
function call, because the stack space reserved by alloca would appear on
the stack in the middle of the space for the function arguments._''
 
</blockquote>
 
---
 
==memcpy==