[Mono-devel-list] Switching to position independent AOT code

Zoltan Varga vargaz at gmail.com
Tue Jan 4 12:39:27 EST 2005


   The amd64 and x86 ports will emit position independent code from now one when
using --aot. This means the runtime does not have to relocate the AOT code when
loading it, allowing multiple runtime processes to share the same code. This 
has some performance impact, but running mcs with all assemblies AOTed is still
faster than running it with the JIT.

The rest of this mail attempts to describe the changes neccesary to
convert a port
to use PIC AOT code.

1. Introduction

Generated native code needs to reference various runtime structures/functions
whose address is only known at run time. JITted code can simple embed the
address into the native code, but AOT code needs to do an indirection. This 
indirection is done through a table called the Global Offset Table (GOT), which
is similar to the GOT table in the Elf spec.  When the runtime saves
the AOT image,
it saves some information for each method describing the GOT table entries
used by that method. When loading a method from an AOT image, the runtime
will fill out the GOT entries needed by the method.

2. Computing the address of the GOT

Methods which need to access the GOT first need to compute its address. On
the x86 it is done by code like this:

call <IP + 5>
pop ebx
add <OFFSET TO GOT>, ebx
<save got addr to a register>

The variable representing the got is stored in cfg->got_var. It is
allways allocated
to a global register to prevent some problems with branches + basic blocks.

3. Referencing GOT entries

Any time the native code needs to access some other runtime structure/function
(i.e. any time the backend calls mono_add_patch_info ()), the code pointed by
the patch needs to load the value from the got. For example, instead of 
it needs to do:
call *<OFFSET>(<GOT REG>)
Here, the <OFFSET> can be 0, it will be fixed up by the AOT compiler.

For more examples on the changes required, see

svn diff -r 37739:38213 mini-x86.c 


More information about the Mono-devel-list mailing list