[PATCH] _dl_find_hash: optmizie symbol lookup delaying stringcomparisons

[Carmelo AMOROSO]

Joakim Tjernlund wrote:
>  
>
>   
>> -----Original Message-----
>> From: Carmelo AMOROSO [mailto:carmelo.amoroso at st.com] 
>> Sent: den 4 oktober 2007 20:00
>> To: Joakim Tjernlund
>> Cc: uclibc
>> Subject: Re: [PATCH] _dl_find_hash: optmizie symbol lookup 
>> delaying stringcomparisons
>>
>> Joakim Tjernlund wrote:
>>     
>>> Hi Carmelo
>>>
>>> This has been up before and I am not convinced it is a gain.
>>> The if (sym->st_value == 0) and if 
>>>       
>> (ELF_ST_TYPE(sym->st_info) > STT_FUNC)
>>     
>>> are mostly false.
>>>
>>> Suggest you get some numbers before applying this patch.
>>>
>>> Jocke
>>>
>>>       
>> Joakim Tjernlund wrote:
>>     
>>> Hi Carmelo
>>>
>>> This has been up before and I am not convinced it is a gain.
>>> The if (sym->st_value == 0) and if 
>>>       
>> (ELF_ST_TYPE(sym->st_info) > STT_FUNC)
>>     
>>> are mostly false.
>>>
>>> Suggest you get some numbers before applying this patch.
>>>
>>> Jocke
>>>
>>>       
>> Hi Jocke, here they are the numbers you were asking for ;-)
>>
>> I've run the uClibc testsuite (using sh4 nptl as usual for me :-) )
>> to collect data.
>>
>> I've executed them (316 tests) in 4 different scenarios:
>>
>> 1) SysV hash - *no* strcmp patch
>> 2) SysV hash - *with* strcmp patch
>> 3) GNU hash - *no* strcmp patch
>> 4) GNU hash - *with* strcmp patch
>>
>> To get figures, I have hacked the ld.so adding a variable
>> to count how many times the ld.so calls a strcmp to check
>> for a symbol matching and it fails, printing it to stderr
>> before the linker passes the control to the application.
>>     
>
> I hope you linked/run with LD_BIND_NOW enabled, else you miss all JMP_SLOT calls
>   
No, only the linker itself is built with -z now so it has BIND_NOW into 
the dynamic section, all other libs
not, and I don't set the LD_BIND_NOW variable at runtime; all JUMP_SLOTs 
are lazily relocated.
I'm counting only the relocation done at startup time.
I don't understand your doubts... I'm missing something?
> your table at the end is somewhat corrupted, but from your description
> I conclude that it is mostly a win for SysV and always for GNU Hash so
> feel free to make the change.
>
>   
GNU hash is a win itself ;-)
>   Jocke
>   
Carmelo