Jump table

__init_array_start _fini_array_start

.word _ctors_start

.section .preinit_array

_preinit_array_start : <-1 Required sections

.word 0xffffffff .word 0x00000000

.section .init_array

_init_array_start:

.word 0xffffffff .word 0x00000000

.section .fini_array

_fini_array_start:

.word 0xffffffff .word 0x00000000

.section .ctors

_ctors_start:

.word 0xffffffff .word 0x00000000

The .text directive indicates that this code should be placed in the .text section of the resulting executable O. The global start directive Q makes the start routine visible to the rest of the application and the linker. The start: © label indicates the first location of the start routine. The mov and add instructions perform some housekeeping Q with the stack pointer, sp, just as seen in the extracted code from the ping program. Initialization takes place via a branch instruction to call the _libc_init routine Q. This routine is found in the library libc.so. When this routine is complete, execution returns to the next instruction, another branch of the main routine G. This is the main() routine implemented by our C application. The next instructions H set up a jump table to the sections required by a C language executable application. A pair of nop instructions round out the table. The sections preinit_array, init_array, fini_array, and .ctors are defined ©. Note that it appears that these sections are required and that the values provided are an allowable address range for these sections. The linker takes care of putting these sections into the resulting executable file. Attempting to run the application without these sections results in code that crashes. I know—I tried!

NOTE All credit for this crt.S file belongs to the author of a blog found at http: //honeypod.blogspot.com/2007/12/initialize-libc-for-android.html. Additional reference material for low-level Android programming information can be found at http://benno.id.au.

Now that we have found an adequate startup routine, let's take a quick look at how to add this routine to our application. The assembly file is handled just like a C language file by the compiler:

arm-none-linux-gnueabi-gcc -c -o crt0.o crt.S

The resulting object file, crtO.o, is passed to the linker as an input file, just as any other object file would be. Also, the entry switch to the linker must now specify _start rather than main:

arm-none-linux-gnueabi-ld --entry=_start --dynamic-linker /system/bin/linker -nostdlib -rpath /system/lib -rpath-link \android\system\lib -L \android\system\lib -l c -l android_runtime -l sqlite -o executablefile csourcefile.o crtO.o

At this point, we are comfortable that we can build applications for Android/Linux, so it's time to build something useful. The next section walks through the construction of a daytime server.

0 0

Post a comment