[CRIU] [PATCHv2] arm/pie/build: do not produce relocatable parasite object

Christopher Covington cov at codeaurora.org
Fri Apr 22 11:20:42 PDT 2016


On 04/22/2016 02:12 PM, Christopher Covington wrote:
> Hi Dmitry,
> 
> On 04/21/2016 02:03 PM, Dmitry Safonov wrote:
>> With `-r` option relocation to parasite_service
>> was not made on ARM:
>> 0x76dbc018:	bl	0x76dbc018		0xebfffffe
>> (You may saw it with objdump also).
>>
>> This leaded to hang at "Putting tsock" message:
>> (01.368297) ----------------------------------------
>> (01.368321)
>> (01.368339) Collecting fds (pid: 13503)
>> (01.368360) ----------------------------------------
>> (01.368535) Found 3 file descriptors
>> (01.368564) ----------------------------------------
>> (01.368648) Dump private signals of 13503
>> (01.368708) Dump shared signals of 13503
>> (01.368761) Parasite syscall_ip at 0x10000
>> (01.369605) Set up parasite blob using memfd
>> (01.369641) Putting parasite blob into 0x76cc5000->0x76e1f000
>> (01.369755) Dumping GP/FPU registers for 13503
>> (01.369818) Putting tsock into pid 13503
>>
>> Also link against native.lib.a
>>
>> Reported-by: alex vk <avankemp at gmail.com>
>> Reported-by: long.wanglong <long.wanglong at huawei.com>
>> Cc: Cyrill Gorcunov <gorcunov at gmail.com>
>> Signed-off-by: Dmitry Safonov <dsafonov at virtuozzo.com>
>> ---
>> v2: drop partial linking only for arm/arm64
>>
>> P.S: please, do not apply, before it doesn't have
>> Tested-by: Wang Long <long.wanglong at huawei.com>
>> as I don't have arm64 board and can't tell if this is
>> the same problem as on RPI2 (armv7) board.
> 
> For what it's worth, I've done most of my AArch64 work on
> qemu-system-aarch64. Example command line:
> 
> qemu-system-aarch64 \
> -nographic \
> -monitor none \
> -M virt \
> -cpu cortex-a57 \
> -m 4G \
> -drive if=none,file=rootfs.img,cache=writeback,id=disk0 \
> -device virtio-blk-device,drive=disk0 \
> -serial stdio \
> -kernel Image \
> -append "root=/dev/vda rw console=ttyAMA0 maxcpus=1 norandmaps"
> -fsdev local,id=r,security_model=none,path=/ \
> -device virtio-9p-device,fsdev=r,mount_tag=passthrough \
> -netdev user,id=mynet0,net=192.168.76.0/24,dhcpstart=192.168.76.9
> -device virtio-net-device,netdev=mynet0
> 
>>  criu/pie/Makefile | 13 +++++++++----
>>  1 file changed, 9 insertions(+), 4 deletions(-)
>>
>> diff --git a/criu/pie/Makefile b/criu/pie/Makefile
>> index 3679e24438a4..4daf77338c85 100644
>> --- a/criu/pie/Makefile
>> +++ b/criu/pie/Makefile
>> @@ -153,19 +153,24 @@ $(obj)/%-blob.h: $(obj)/%.built-in.bin.o $(SRC_DIR)/compel/compel
>>  
>>  else # !piegen-y
>>  
>> +# ld on arm doesn't like -pie and -r options together
>> +ifeq ($(filter arm arm64,$(ARCH)),)
>> +        LD_R := -r
> 
> I think this is conventionally named LDFLAGS.

Although a user might expect to be able to set LDFLAGS on the command
line. With that in mind, I think LD_R is fine. If you do want to go with
LDFLAGS, consider using override (just for pie/Makefile, ideally letting
the user play with LDFLAGS elsewhere).

>> +endif
>> +
>>  define gen-rule-built-in.bin.o
>>  $(obj)/parasite-$(1).built-in.bin.o: $(obj)/$(1).built-in.o		\
>> -				$(obj)/pie.lds-$(1).S
>> +				$(obj)/pie.lds-$(1).S $(obj)/native.lib.a
>>  	$$(call msg-gen, $$@)
>> -	$(Q) $(LD) -r -T $(obj)/pie.lds-$(1).S -o $$@ $$<
>> +	$(Q) $(LD) $(LD_R) -T $(obj)/pie.lds-$(1).S -o $$@ $$< $(obj)/native.lib.a
> 
> Could you use "$$^" instead of "$$< $(obj)/native.lib.a"?
> 
>>  endef
>>  
>>  $(eval $(call map,gen-rule-built-in.bin.o,$(parasite_target)))
>>  
>>  $(obj)/restorer.built-in.bin.o: $(obj)/restorer.built-in.o		\
>> -				$(obj)/pie.lds-native.S
>> +				$(obj)/pie.lds-native.S $(obj)/native.lib.a
>>  	$(call msg-gen, $@)
>> -	$(Q) $(LD) -r -T $(obj)/pie.lds-native.S -o $@ $<
>> +	$(Q) $(LD) $(LD_R) -T $(obj)/pie.lds-native.S -o $@ $< $(obj)/native.lib.a
>>  
>>  $(obj)/%.built-in.bin: $(obj)/%.built-in.bin.o
>>  	$(call msg-gen, $@)
>>
> 
> Thanks,
> Christopher Covington
> 


-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


More information about the CRIU mailing list