Library Calls: Difference between revisions

The '''linker''' is a different story. When the compiler is done compiling your source file into object files, it is up to the linker to '''link''' all object files together into an executable. It also '''resolves symbols'''. For the above code, the object code refers to a function ''<tt>printf()''</tt> which is, however, '''not defined''' in the object code itself.

=== [[GCC Cross-Compiler]] ===

Well, the usual userspace process for a library call is already explained above, is it? Well, yes, but only at a high level. What actually '''happens''' when you call ''<tt>printf()''</tt> like that?

Your userland =<tt>printf()=</tt> does not have a string to print, yet - only a parameter that happens to be an integer, and a manual on how to make a string of it. It then proceeds to construct that very string, "The answer is 42!\n". In some way. Doesn't matter.

So let's say your standard library implementation of ''<tt>printf()''</tt>, after assembling the string to be printed, calls a function named ''<tt>write()''</tt>, passing it a pointer to the readily-assembled string and the information that it is to be printed to stdout - like, the integer 1.

''<tt>write()''</tt> now does something special: It places a special code into one register, the ''char *'' and the integer in some others, and calls an '''interrupt'''.

An interrupt ends userspace processing, and wakes up the kernel - more specifically, the interrupt handler registered by the kernel. Since it was the interrupt reserved for '''system calls''', it knows what to do: The special code tells it that it was ''<tt>write()''</tt> calling the interrupt. That means that there is a ''char *'' in '''this''' register, and an ''int'' in '''that'''... oh, it's a 1, so this goes to stdout (instead of, say, a file).

The interrupt handler ends, ''<tt>write()''</tt> is back in control, which returns to ''printf()'' which returns to your application. You successfully completed a call to ''<tt>printf()''</tt>.

If you are in kernel space anyway, you don't want that hassle with the registers and the interrupt. After all, you '''can''' call the print function directly as you '''are''' in kernel space. You also never want to write to a file. The ''<tt>write()''</tt> function and the interrupt handler become unnecessary baggage.

'''And''' you probably don't want all the code necessary for e.g. floating point conversions or unicode output linked into your kernel binary, either. The userspace ''<tt>printf()''</tt> is much too heavy for your tastes.

So you provide a lightweight ''<tt>printf()''</tt> for kernel space. You don't even have to bother to call it ''<tt>kprintf()''</tt> or something as your kernel binary will never be '''linked''' with userspace code. Using some preprocessor ''#ifdef'' magic, you can even use the very same ''<stdio.h>'' header file as for userspace code, reducing redundancy and potential error sources: The preprocessor symbol STDC_HOSTED<tt>__STDC_HOSTED__</tt> (with two leading and trailing underscores that the Wiki stubbornly interprets as boldface markup) is undefined when you set ''-ffreestanding''...