[CRIU] [PATCH 3/4] vdso: Rework vdso processing files

[Christopher Covington]

On 09/15/2015 05:36 PM, Christopher Covington wrote:
> On 09/15/2015 11:56 AM, Laurent Dufour wrote:
>> On 15/09/2015 17:38, Christopher Covington wrote:
>>> On 09/15/2015 11:14 AM, Laurent Dufour wrote:
>>>> On 15/09/2015 17:01, Christopher Covington wrote:
>>>>> On 09/15/2015 09:54 AM, Christopher Covington wrote:
>>>>>
>>>>>>> -int vdso_fill_symtable(char *mem, size_t size, struct vdso_symtable *t)
>>>>>>> -{

>>>>>>> -	const char *vdso_symbols[VDSO_SYMBOL_MAX] = {
>>>>>>> -		[VDSO_SYMBOL_CLOCK_GETRES]	= VDSO_SYMBOL_CLOCK_GETRES_NAME,
>>>>>>> -		[VDSO_SYMBOL_CLOCK_GETTIME]	= VDSO_SYMBOL_CLOCK_GETTIME_NAME,
>>>>>>> -		[VDSO_SYMBOL_GETTIMEOFDAY]	= VDSO_SYMBOL_GETTIMEOFDAY_NAME,
>>>>>>> -		[VDSO_SYMBOL_RT_SIGRETURN]	= VDSO_SYMBOL_RT_SIGRETURN_NAME,
>>>>>>> -	};
>>>>>
>>>>> It looks like making vdso_symbols global was the problem. Any objections to
>>>>> moving the definition (the version that uses architecture-provided macro
>>>>> ARCH_VDSO_SYMBOLS) inside the vdso_fill_symtable function?
>>>>
>>>> The main objection here is the stack's usage, but this table is not so
>>>> big so...
>>>
>>> On this point, it's const, so I didn't expect it to be allocated on the stack.
>>
>> So if it is not allocated on the stack, it will put in the data (or
>> code) area like the original declaration, what's the change ?
>>
>>>> Anyway, my fear here is that this hiding a more complex issue relative
>>>> to the PIE's code and the underlying relocation. Isn't it ?
>>>
>>> That could be.
>>
>> I got similar issue before the relocation was in place in the parasite
>> code. May be this is the same case here. May be you should have a look
>> to that part for aarch64 ?
> 
> I've patched my kernel so that your vdso_remap.c test case passes, but that
> doesn't fix this issue. I'm thinking the best debug strategy for me is to
> fiddle with some minimal test cases, one where the array is global, and one
> where it's got function scope, and look closely at the objdump and maybe some
> instruction traces to understand the generated assembly and why one works and
> the other doesn't under. My naive expectation is that when one passes
> aarch64-linux-gnu-gcc the -pie flag, all address calculations are done in a
> PC-relative manner, but perhaps there are limitations on what can be made
> PC-relative, or there are toolchain bugs, or there are extra flags that need
> to be provided.

In working, local array case:

pie/util-vdso.o has no .data.rel.local nor .rela.data.rel.lo section.
Relocations in .rela.text are to .rodata.str1.8 or print_on_level. In the
generated assembly, an add instruction is used to compute a PC-relative address.

In the non-working, global array case:

pie/util-vdso.o has both .data.rel.local and .rela.data.rel.lo sections.
Some relocations in .rela.text are to .data.rel.local. In the generated
assembly, a load instruction is used to look up the address, although I'm not
yet sure where from.

This may not be relevant to the problem at hand but something I noticed is
that while -fPIE is passed to gcc during the compilation phase, -pie is never
passed to ld during the final linking step (although the mutually exclusive -r
flag is passed to ld during intermediate but non-final linking steps). If
anyone knows why this is, I'd like to learn.

Thanks,
Christopher Covington

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