[CRIU] Re: [PATCH 3/6] make: Redesign building of parasite and restorer blobs

Pavel Emelyanov xemul at parallels.com
Wed Mar 28 05:53:42 EDT 2012


On 03/27/2012 11:40 PM, Cyrill Gorcunov wrote:
> On Tue, Mar 27, 2012 at 11:35:15PM +0400, Pavel Emelyanov wrote:
>> On 03/27/2012 06:45 PM, Cyrill Gorcunov wrote:
>>>
>>> In order to make further modifications of parasite
>>> and restorer blobs easier the following is done
>>>
>>>  1) Everything related to parasite/restorer is moved
>>>     into separate Makefile.pie because there are special
>>>     rules needed to build this files so escape messing with
>>>     general Makefile
>>
>> What are the rules?
> 
> -fpie and only one .text section with everything else discarded.

And why do we need separate Makefile for this then?

>>
>>>  2) No need to host two lds files which do the same thing,
>>>     just merge them into one pie.lds.S.
>>
>> What about symbol names? They are not the same for parasite
>> and restorer.
> 
> symbol names has nothing to do with ld script, the symbols are
> generated from source code and ld doesn't touch them.

In the parasite.lds there's the *(.parasite.head.text) statement, in the
restorer.lds -- the *(.restorer.head.text) one.

Why do you create one pie.lds file for both with *(.parasite.head.text)?

>>
>> And this can be separate patch.
>>
>>>  3) Tune up restorer-log.c functions declarations, they
>>>     are not always_inline but merged into built file with
>>>     ld help
>>
>> This can be a separate patch as well.
> 
> nope, if function become not always inlined, there is no
> guarantee where it goes in result file, so better make all
> this in one set
> 
>>
>>>  4) Along with .bin files generate correspond .bin.o files
>>>     in debug purpose (one could disassemble them and check
>>>     the contents).
>>
>> This can be separate patch as well.
> 
> Sure this one can be done in separate patch, but Pavel it's
> just one line in makefile, where makefile is completely rewritten
> so there is NO benefit in patching it separately.

Anyway.

> 	Cyrill
> _______________________________________________
> CRIU mailing list
> CRIU at openvz.org
> https://openvz.org/mailman/listinfo/criu
> .
> 



More information about the CRIU mailing list