Calling Global Constructors: Difference between revisions

To understand this apparent complexity, consider a program consisting of <tt>foo.o</tt> and <tt>bar.o</tt> that is being linked:

The compiler will rewrite the command line and pass it to the linker as:

The idea is that the these files together form the <tt>_init</tt> and <tt>_fini</tt> functions during the linking. This is done by storing the <tt>_init</tt> function in the <tt>.init</tt> section, and the <tt>_fini</tt> function in the <tt>.fini section</tt>. Each file then contributes a bit to these sections and the linker makes glues together the fragments in the code specified on the command line. <tt>crti.o</tt> provides the function header, <tt>crtbegin.o</tt> and <tt>crtend.o</tt> provide the body, and <tt>crtn.o</tt> provide the footer (return statement). It is important to understand that the link order matters and strange things may happen if the objects is not exactly linked in this order.

As a special extension, GCC allows C programs to run functions as global constructors. For more information, consult the compiler documentation. This is normally used as:

__attribute__ ((constructor)) void foo(void)

{

printf("%s: main is running with argc=%i\n", argv[0], argc);

}

=== Using crti.o, crtbegin.o, crtend.o, and crtn.o in a Kernel ===

In a kernel, you are not using a user-space C library. You may be using a special kernel "C library", or none at all. The compiler always supplies <tt>crtbegin.o</tt> and <tt>crtend.o</tt>, but normally the C library supplies <tt>crti.o</tt> and <tt>crtn.o</tt>, but not in this case. The kernel should supply its own <tt>crti.o</tt> and <tt>crtn.o</tt> implementation (even if it would be otherwise identical to the user-space libc version). A kernel is linked with <tt>-nostdlib</tt> (which is the same as passing <tt>-nodefaultlibs</tt> and <tt>-nostartfiles</tt>) which disables the "start files" <tt>crt*.o</tt> that are normally automatically added to the link command line. By passing <tt>-nostartfiles</tt>, we promise to the compiler that we take on the responsibility ourselves to call the "program initialization tasks" in the <tt>crtbegin.o</tt> and <tt>crtend.o</tt> files. This means as we need to manually add <tt>crti.o</tt>, <tt>crtbegin.o</tt>, <tt>crtend.o</tt>, and <tt>crtn.o</tt> to the command line. Since we provide <tt>crti.o</tt> and <tt>crtn.o</tt> ourselves, that is trivial to add to the kernel command line. However, since <tt>crtbegin.o</tt> and <tt>crtend.o</tt> are installed inside a compiler-specific directory, we'll need to figure out the path. Luckily, gcc offers an option just to do this. If <tt>i686-elf-gcc</tt> is your cross-compiler and <tt>$CFLAGS</tt> is the flags you would normally provide to your compiler, then

will make the compiler print the path to the correct <tt>crtbegin.o</tt> file (that is ABI compatible with the $CFLAGS options) to the standard output. The same works with <tt>crtend.o</tt>. If you are using GNU Make, you can do it easily in your makefile assuming <tt>$(CC)</tt> is your cross-compiler and <tt>$(CFLAGS)</tt> is the flags you would normally pass it:

CRTBEGIN_OBJ:=$(shell $(CC) $(CFLAGS) -print-file-name=crtbegin.o)

CRTEND_OBJ:=$(shell $(CC) $(CFLAGS) -print-file-name=crtend.o)

You can then use them as such (adapted to your real build system):

OBJS:=foo.o bar.o

clean:

rm -f myos.kernel $(INTERNAL_OBJS)

It is important to remember that the objects must be linked in this exact order, or you will experience strange bugs.

The solution is to provide your own <tt>crti.o</tt> object that inserts a symbol at the start of <tt>.init_array</tt> and <tt>.fini_array</tt> sections, as well as your own <tt>crtn.o</tt> that inserts a symbol at the end of the sections. In this case it is actually possible to write <tt>crti.o</tt> and <tt>crtn.o</tt> in C, because we are not writing incomplete functions. These files should be compiled like the rest of your kernel and otherwise used normally as <tt>crti.o</tt> and <tt>crtn.o</tt>.

/* crti.c for ARM - BPABI - use -std=c99 */

typedef void (*func_ptr)(void);

func_ptr _init_array_start[0] __attribute__ ((used, section(".init_array"), aligned(sizeof(func_ptr)))) = { };

func_ptr _fini_array_start[0] __attribute__ ((used, section(".fini_array"), aligned(sizeof(func_ptr)))) = { };

/* crtn.c for ARM - BPABI - use -std=c99 */

typedef void (*func_ptr)(void);

func_ptr _init_array_end[0] __attribute__ ((used, section(".init_array"), aligned(sizeof(func_ptr)))) = { };

func_ptr _fini_array_end[0] __attribute__ ((used, section(".fini_array"), aligned(sizeof(func_ptr)))) = { };

Additionally, if you use constructor/desctructor priorities, the compiler will append these priorities to the section name. The linker script is expected to expected to sort these, so you will have to add the following to your linker script. Note that we have to treat the <tt>crti.o</tt> and <tt>crtn.o</tt> objects specially because we need to put the symbols in the right order. Alternatively, you can emit the <tt>_init_array_start</tt>, <tt>_init_array_end</tt>, <tt>_fini_array_start</tt>, <tt>_fini_array_end</tt> symbols yourself from the linker script.