[CRIU] Re: [PATCH 4/6] parasite: Bind parasite data to own data section

Cyrill Gorcunov gorcunov at openvz.org
Tue Feb 14 09:56:38 EST 2012


On Tue, Feb 14, 2012 at 06:19:09PM +0400, Pavel Emelyanov wrote:
> On 02/14/2012 05:41 PM, Cyrill Gorcunov wrote:
> > To eliminate binding to .bss section (we don't have own
> > section loader, so that data variables must not be shrinked).
> 
> What problem do we solve here? I thought Andrey did it so that
> the parasite is a single .o file compiled out of several other .o
> ones and that's it.
> 

Pavel, the problem comes from code gcc generates and how we do
use it. When gcc generates code for us it produces completely
valid elf files with (!) relocations and it's implied that
facilty which uses generated object files (either ld, either
any other linker or loader in case of executable files) takes
relocations into accounts.

But when we link parasite code we simply count everything from
zero, which (seems) to be more or less OK for now but never guaranteed
to work always. And when we linked several .o files into one
binary -- I'd missed this fact of potential problems we might
have in future.

So what I'm trying to achieve now -- unweave all this, and make
parasite (and potentially restorer) code to be single .o files
which we will be able to parse, read relocs, apply them and load
into alien process memory after.

Another option is to produce parasite.so and restorer.so, which
we upload manually when needed. But I didn't consider potential
tech problem we might face then yet ;)

All-in-one, please drop this series I'll think a bit more...

	Cyrill


More information about the CRIU mailing list