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

[Laurent Dufour]

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)
>>>>> -{
>>>>> -	Elf64_Phdr *dynamic = NULL, *load = NULL;
>>>>> -	Elf64_Ehdr *ehdr = (void *)mem;
>>>>> -	Elf64_Dyn *dyn_strtab = NULL;
>>>>> -	Elf64_Dyn *dyn_symtab = NULL;
>>>>> -	Elf64_Dyn *dyn_strsz = NULL;
>>>>> -	Elf64_Dyn *dyn_syment = NULL;
>>>>> -	Elf64_Dyn *dyn_hash = NULL;
>>>>> -	Elf64_Word *hash = NULL;
>>>>> -	Elf64_Phdr *phdr;
>>>>> -	Elf64_Dyn *d;
>>>>> -
>>>>> -	Elf64_Word *bucket, *chain;
>>>>> -	Elf64_Word nbucket, nchain;
>>>>> -
>>>>> -	/*
>>>>> -	 * See Elf specification for this magic values.
>>>>> -	 */
>>>>> -	const char elf_ident[] = {
>>>>> -		0x7f, 0x45, 0x4c, 0x46, 0x02, 0x01, 0x01, 0x00,
>>>>> -		0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
>>>>> -	};
>>>>> -
>>>>> -	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 ?

Cheers,
Laurent.