[CRIU] [PATCH] pie: Give VDSO symbol table local scope

[Christopher Covington]

On 10/05/2015 12:44 PM, Laurent Dufour wrote:
> On 05/10/2015 17:30, Christopher Covington wrote:
>> Hi Laurent,
>>
>> On 10/05/2015 10:54 AM, Laurent Dufour wrote:
>>> On 03/10/2015 14:47, Christopher Covington wrote:
>>>> In commit c2271198, Laurent Dufour kindly reunified the VDSO code
>>>> that had become duplicated between architectures. Unfortunately
>>>> this introduced a regression in AArch64 where apparently due to
>>>> the scope of vdso_symbols array of pointers to characters changing
>>>> from local to global, load-time relocations became necessary.
>>>>
>>>> The following thread on the GCC mailing list discusses why
>>>> load-time relocations can be necessary when pointers are used,
>>>> although it doesn't mention the potential for locally scoped
>>>> arrays to be handled differently:
>>>> https://gcc.gnu.org/ml/gcc/2004-05/msg01016.html
>>>>
>>>> Because the alternatives, such as porting piegen to AArch64, are
>>>> far more involved, simply revert the change in scope.
>>>
>>> Hi Christopher,
>>>
>>> This breaks the build on powerpc due to the gcc optimisation done on power.
>>>
>>> On power the compiler is calling C library memcpy to copy the
>>> pre-initialised. This leads to an undefined memcpy symbol when building
>>> the parasite part.
>>> I'm looking at the best way to get around that.
>>
>> Sorry about that. Here are some thoughts:
>>
>> A) #ifdefs
>>
>> Ideally with some comments and only temporary until we work out a more
>> satisfactory solution.
>>
>> B) Keep the declaration local but make it static const instead of just const
>>
>> You've probably already seen this, but this approach is mentioned in the
>> comments here:
>> http://stackoverflow.com/questions/6410595/getting-gcc-to-compile-without-inserting-call-to-memcpy
> 
> This works for me, but I would be surprised that it works on ARM without
> any relocation in place. Isn't it?

A quick test shows it working on AArch64, but `aarch64-linux-gnu-readelf -r`
does show a local relocation being added. I'm not entirely sure what's going on.

(It's been a while since I tested AArch32. The AArch32 kernel got VDSO support
somewhat recently. It looks like I need to enable VDSO support in 32-bit ARM
CRIU the first place for that to progress.)

>> D) Port piegen to AArch64
>>
>> I'd like to do this at some point, if only as an exercise to learn more about
>> ELF and AArch64, but I'm not sure I'll have to the time to do it in the next
>> few weeks.
> 
> I guess at one time this will be required, because there are other place
> where such a declaration could be made.

Agreed.

> There is another option :
> E) Pn powerPC, since the compiler relies on memcpy to set the data in
> the stack, define a memcpy service in vdso-pie.c. This way even if there
> are other similar declaration, this should work.
> 
> I think I will implement the option E) even if B) works fine on power,
> this may be convenient in the future.

Sounds good to me.

Regards,
Christopher Covington

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