prelink breaks fdpic support in a bunch of places

[Carmelo AMOROSO]

On 28/11/2011 13.18, Filippo ARCIDIACONO wrote:
> Hi Mike,
> 
>> -----Original Message-----
>> From: Mike Frysinger [mailto:vapier at gentoo.org]
>> Sent: Sunday, November 27, 2011 9:12 AM
>> To: uclibc at uclibc.org; filippo.arcidiacono at st.com;
>> carmelo.amoroso at st.com
>> Subject: prelink breaks fdpic support in a bunch of places
>>
>> there seems to be a bunch of changes that the associated changelog does
>> not seem to cover.  so i don't know if they were changed on purpose, by
>> accident, etc...
>>
>>> commit a33796043bdef5345bc00a528c942f91a87af8e9
>>> ldso: Add runtime prelink support
>>>
>>> _dl_load_elf_shared_library(int secure,...) ...
>>> -	DL_LOADADDR_TYPE lib_loadaddr;
>>> +	DL_LOADADDR_TYPE lib_loadaddr = 0;
>>
>> why is this necessary ?  nothing else in this func changed.  you can't
>> assign directly to a variable of type DL_LOADADDR_TYPE.
> 
> You are right. I missed DL_LOADADDR_TYPE for archs not sh.
> 
>>
>>> int _dl_fixup(struct dyn_elf *rpnt, struct r_scope_elem *scope, int
>>> now_flag) ...
>>> -	elf_machine_relative(tpnt->loadaddr, reloc_addr, relative_count);
>>> +	if (tpnt->loadaddr
>>> +#ifdef __LDSO_PRELINK_SUPPORT__
>>> +		|| (!tpnt->dynamic_info[DT_GNU_PRELINKED_IDX])
>>> +#endif
>>> +		)
>>> +		elf_machine_relative(tpnt->loadaddr, reloc_addr,
>> relative_count);
>>
>> why is tpn->loadaddr now being checked ?
> 
> 

Apart the issue with archs where loadaddr is not a plan address value,
I'm pretty sure that we added the check as a sort of optimisation,
assuming that elf_machine_relative should not be called if loadaddr was
0, but indeed there are some architecture (that have RELA relocations)
for which that function should be called in any case.

I suspect that this is one of the possible problem we introduced and
that Khem is seeing.
We are posting a experimental patch.

Carmelo