[PATCH 2/2] ldso: make hashcode handling more generic

Chris Zankel chris at zankel.net
Thu Nov 7 21:52:51 UTC 2013


Hi Rich,

Thanks for your feedback.

On 11/6/13, 9:27 PM, Rich Felker wrote:
> On Wed, Nov 06, 2013 at 11:23:06AM +0200, Baruch Siach wrote:
>> The hashcode handling code never accesses the underlying structure
>> 'struct funcdesc_value', but only operates on pointer to pointers,
>> so we can use void** instead.
> No you can't. This is an aliasing violation, and a compiler performing
> LTO would be free to reorder accesses in such a way as to horribly
> break things. However it appears the code may already contain some

I think the original comment was a bit misleading, and I'm not sure how 
to really word it. However, I fail to see where the aliasing violation 
would be, but admit that I might be missing something.

The hashcode routine handles pointers, and they are never dereferenced. 
My understanding is that void* is guaranteed to hold any pointer (in 
size and alignment) and allows assignment to any other pointer (T* <-> 
void*). In that case, it would be save to have a table of pointers 
(void* table[]) and cast between T* and table[i]. This seems to be the 
essence of that code.

> similar aliasing violations. This should be investigated before any
> further changes are made.
Would be great if you could point me to those violations. Note that I'm 
not trying to defend the actual implementation of that code, but it is 
also used that way in glibc, so we should only rewrite or fix if and 
what is necessary.

Thanks,
-Chris



More information about the uClibc mailing list