[BUG] error in global variables strong aliasing

[Amir Shalem]

Peter S. Mazinger wrote:
> On Sat, 18 Mar 2006, Amir Shalem wrote:
>
>   
>> hey,
>>
>>
>> after commit http://www.uclibc.org/lists/uclibc-cvs/2006-March/009686.html
>>
>> global variables such as environ, errno, and friends are broken
>>
>> when compiling against uclibc dynamiclly only.
>>     
>
> maybe
>
> for _errno, that shouldn't be even exported, but is used by linuxthreads, 
>   
maybe for ernno but for environ its a bug.
because what happens is that uClibc modifies __environ variable
where as busybox ash shell uses environ variable
and because of strong aliasing (with weak aliasing it works ok)
__environ and environ takes two different addresses when the program runs.

this of course causes the ash shell to give malformed environment in shell.
for me it gives an empty environment.

please note that the environment variable passed to main() is ok,
its the global environ variable which is problematic.

>   
>> you can check it out using:
>>
>>
>> /* errno and _errno are strongly aliased */
>>
>> extern int errno;
>>     
>  ^^^
> man page says: don't do that, it will not work with modern versions of the 
> C library (this is probably true for uClibc if we will get TLS working)
>   
the problem isn't with errno, and using errno like this is wrong
the problem is with strong aliasing between _errno and errno.
>   
>> extern int _errno;
>>
>>
>> int main(void)
>>
>> {
>>     errno = 0;
>>
>>     _errno = 1;
>>
>>     printf("errno: %d _errno: %d\n", errno, _errno);
>>
>>     return 0;
>>
>> }
>>
>>
>> if you compile this program staticlly you will see same result (=1) in 
>> both variables,
>>
>> but if you compile this program dynamiclly you will see diffrent results.
>>     
>
> I have the same result (=1) dynamically (x86 native)
>   
with the latest snapshot version of uClibc, this code gives me different 
values when compiling dynamically (x86 native)
>   
>> same happens with __environ & environ.
>>     
>
> this one is curious, I had a bug report before yours when I made use of 
> hidden global data (what this svn commit undid due to stability problems)
>   
yes, see the bug which is caused of different addresses of environ, 
__environ at the start of mail.
>   
>> if changing to weak_alias (instead of strong_alias) it works again.
>>     
>
> on which arch?
>   
x86 native.
>   
>> you can simulate this bug by creating a library from:
>>
>>          int var = 0;
>>
>>          extern int var2 __attribute__ ((alias ("var")));
>>
>>
>> and then play with 'var' and 'var2'.
>>
>>
>> I have manage to reproduce it with gcc 3.4.4 + binutils 2.15 + FreeBSD 6.1,
>>     
>
> what does FreeBSD mean here, your host OS? have you used buildroot?
>   
different host machine
>> and using gcc 4.1.0 + binutils 2.16.1 + uClibc 20060317
>>     
>
> how can this be compared to the above, is this native?
>   
I have tested the test-case which I provided above, and on both it gave 
two different addresses in both cases
which means strong aliasing gives strange results with older 
gcc/binutils versions too.
>> Amir.
>>     
>
> thanks, Peter
>
>