Re: [Tinycc-devel] Call for testing

[Thomas Preud'homme]

Le jeudi 24 janvier 2013 11:35:30, Thomas Preud'homme a écrit :
> 
> I finally got around to look in this last failure. I just started but the
> good news is that it's limited to the -run function. There is no problem
> when compiling the example. Objdump shows it's the exact same code in both
> case. So it's probably a relocation bug.

Ok got it. Fix attached. I'm not sure about the comments though, as I don't 
have all the details in my mind. Let me explain a bit what's going on and you 
might have idea about the details.

The segfault happens when calling a function whose symbol is resolved by 
calling a function first (symbol is of type STT_GNU_IFUNC) and that you resolve 
the symbol later via a call to dlsym. In the case of the 28_strings test, tcc 
was calling strcpy and then while doing -run, it performed a dlsym for the 
first symbol it encountered in 28_strings.c: strcpy.

The problem is that tcc, when linking, was copying the type for functions 
symbol (STT_FUNC and STT_GNU_IFUNC) in the resulting executable.

I'm not sure about the details but what happens is that the first call to 
strcpy will save call the dynamic resolver which will call the function to 
decide which version of strcpy to use (like strcpy_sse2 or strcpy__ssse3) and 
then the resulting address was stored somewhere (I always forget the details 
about where is the results stored, is it just in the GOT of the executable?).

Then, the dlsym would take the address stored and do the relocation again. 
Except that this time the adress points to one of the implementation of strcpy 
(strcpy_ssse3 on my computer) which would get executed to get the final 
address. So strcpy would be executed with whatever happens to be in the 
registers at the time of calling dlsym. Setting the symbol as STT_FUNC in the 
executable would mean that the dlsym would get the address of the resolving 
function which would return the address of the right variant of strcpy.

So, all I can say is that using STT_FUNC instead of STT_GNU_IFUNC in the 
*executable* only affects the normal call, which would store the address of the 
resolving strcpy function instead of the strcpy variant directly.

If someone can throw some light to where are things stored or suggest me a 
comment, I'd be very happy.

Best regards,

Thomas

fix_ifunc_dlsym_after_ifunc.patch
Description: Text Data

signature.asc
Description: This is a digitally signed message part.