[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