[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ELF Relocations and OCaml Code


Yesterday I had a strange issue with unsupported ELF relocations while
building a kernel module out of OCaml programs for FreeBSD/amd64.  I have
finally resolved the problem, but Anil suggested me to send in here for the

I am working on the FreeBSD port of the Mirage OS module.  Everything seemed
to compile and link fine, until I wanted to load the module using the
kldload(8) command:

# kldload mirage.ko

Then the console was pounded by lot of linker errors:

kldload: unexpected relocation type 9
kldload: unexpected relocation type 4
link_elf_obj: symbol camlPervasives__entry undefined
linker_load_file: Unsupported file type

kldload: can't load mirage.ko: Exec format error

By browsing the kernel sources, it turned out that the 64-bit FreeBSD kernel
does not support ELF relocation types 9 (R_X86_64_GOTPCREL), 10 (R_X86_32) and
4 (R_X86_64_PLT32) (among many others).

So, in order to get rid of these, I had to compile all my OCaml sources as
position-dependent code, without support for dynamic linking.  This means that
ocamlopt must be called with the following flags: -fno-PIC and -nodynlink.

In addition, a custom OCaml stdlib has to be built in the same fashion and
used when compiling the sources.  (By the way, I use -output-obj to get a
large C object file with all the referenced code, so it could be linked into
the kernel module.)  This can be overridden by setting the CAMLLIB
environmental variable.

However, note that, in the OCaml run-time sources (which gets finally linked
to the generated object code) the file called amd64.S should be also modified
to remove the last pieces of PIC addressing.  That is, the lines

#define GREL(r) r@GOTPCREL
#define GCALL(r) r@PLT

should be rewritten as

#define GREL(r) r
#define GCALL(r) r

One can always check if there is any PIC object left in the ELF by using

# readelf -r mirage.ko | grep -E "(PLT32|GOTPCREL)"

Obviously, do not forget to compile all the referenced OCaml modules in the
same way.



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.