[BUG] error in global variables strong aliasing

Peter S. Mazinger ps.m at gmx.net
Fri Mar 24 16:43:51 UTC 2006


On Fri, 24 Mar 2006, Amir Shalem wrote:

> 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.

I need more details from you, I have to be able to reproduce it, because I 
can't here, I have the same in both.

> 
> 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)

forgotten to mention my environment is x86 uClibc native, no 
cross-compiling

> >   
> with the latest snapshot version of uClibc, this code gives me different 
> values when compiling dynamically (x86 native)

glibc or uClibc 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

Please provide all steps to reproduce it

Thanks, Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2




More information about the uClibc mailing list