[CRIU] parasite/restorer code and relocations problem
Cyrill Gorcunov
gorcunov at openvz.org
Sun Mar 18 12:17:38 EDT 2012
Hi guys,
here is a description for major issue we have now (which just
happened to not hit us by luck but it's still here).
The parasite and restorer code is supposed to be position
independent code, mostly because we don't know at moment
of compilation which addresses we will use for them in
dumpee (or restorer) space.
Both -pic (or actually we need -pie option here instead)
do not solve this problem completely and we still have
relocation references in both parasite.o/restorer.o.
At moment it just happened to work due to debug options
passed to compiler but this is a time-bomb. I fear one
day we will hit the problem when compiler+linker
(due to optimisation or any other reason) generate
absolute address in instruction and we spend days
trying to cath the problem (actually I _have_ spent
a couple of days before I realised why the hell
optimized version of crtools fails somewhere in
parasite space which is almost impossible to
debug without special tricks).
What I think should be done
- with help of compiler and linker the predefined
structure of object file will be generated (only
.text/.data/.bss sections)
- at moment of compilation we do stream such .o
file into byte array and compile it into the
crtools itself
- when crtools executes we
- provde a memory space for all sections
- upload the sections
- apply relocations
- finally we pass execution to .text section
Ie this is kind of mini-elf loader, it should not
be big just around 100-200 lines of code.
The same applies to restorer code.
I've started to work on this and already have
a miniparser (I actually don't wanna create some
'general' parser or say use BDF library here,
because it is either a way more work to do or
in case of BDF we become dependent on this library).
If someone knows some other way how to handle this
problem -- I'm all hearing ;)
Cyrill
More information about the CRIU
mailing list