On Thursday 19 February 2009 09:14:09 pm rhabarber1848 wrote:
> Hi,
>
> first of all I must note that I am not a C/C++ expert, I am only trying to
> hack something together in order to make things work;)
>
> The Tuxbox project, a set of drivers and GUIs for a digital TV settop box
> with powerpc cpu, can be used with uClibc 0.9.30 successfully. Currently I
> am testing its compatability with uClibc SVN head and already solved two
> problems, one yesterday by deactivating UCLIBC_HAS_LONG_DOUBLE_MATH, the
> other problem is related to a gcc patch which enables uClibc locales in
> libstdc++[1].
>
> But there is another problem which breaks a lots of apps, luckely not
> including Busybox. I tested a lot of SVN revisions in order to find the one
> introducing the bug.
>
> SVN rev 24361 is the latest working revision.
> http://sources.busybox.net/index.py?view=rev&revision=24361
>
> SVN rev 24362 does not compile,
> http://sources.busybox.net/index.py?view=rev&revision=24362
> it shows this error:
> > LD libpthread-0.9.30-svn.so
> > libpthread/linuxthreads.old/libpthread_so.a(wrapsyscall.os): In function
> `fcntl':
> > (.text+0xb8): undefined reference to `__libc_fcntl'
>
> SVN rev 24363 does not compile either
> http://sources.busybox.net/index.py?view=rev&revision=24363
> it shows this error:
> > STRIP -X --strip-debug -R .note -R .comment
> libpthread/linuxthreads.old/libpthread_so.a
> > LD libpthread-0.9.30-svn.so
> > libpthread/linuxthreads.old/libpthread_so.a(wrapsyscall.os): In function
> `close':
> > (.text+0x24): undefined reference to `__libc_close'
> > libpthread/linuxthreads.old/libpthread_so.a(wrapsyscall.os): In function
> `fcntl':
> > (.text+0xb8): undefined reference to `__libc_fcntl'
> and about 20 similar errors more...
>
> The next SVN rev 24366 (no other patches included, the uClibc_locale.h
> problem which breaks libstdc++ compilation was introduced in SVN rev 24565)
> is the first compiling version of uClibc which breaks most Tuxbox apps,
> details about the breakage will follow later.
>
> Because I can not test revs 24362 + 24363 I am handling 24362, 24363 and
> 24366 as a complete package and did the following:
> extracted uClibc 0.9.30 tarball, patched to SVN rev 25370, then commits from
> SVN revs 24362, 24363 and 24366 are removed and the uClibc locale patch[1]
> is applied. Using this uClibc code I was able to create a working Tuxbox
> environment again, so one of the patches from SVN revs 24362, 24363 or
> 24366 is responsible for the problem. I am not able to identify which part
> of these commits might be responsible for the problem. I included that
> patch as uclibc_svn3.diff.bz2.
>
> I am not sure how many apps are affected of this problem, I tested it using
> a small app which uses threads and segfaults when started, other system
> critial daemons are affected as well, breaking the Tuxbox software package
> completely.
The patch is showing it quite clearly:
--- uClibc-0.9.30.24366/libpthread/linuxthreads.old/wrapsyscall.c
2009-02-19 13:41:18.000000000 +0100
+++ uClibc-0.9.30.24361/libpthread/linuxthreads.old/wrapsyscall.c
2008-10-17 13:38:08.000000000 +0200
@@ -41,35 +41,35 @@
#endif
-#define CANCELABLE_SYSCALL(res_type, name, param_list, params)
\
-res_type name param_list;
\
-res_type
\
-__attribute__ ((weak))
\
-name param_list
\
-{
\
- res_type result;
\
- int oldtype;
\
- pthread_setcanceltype (PTHREAD_CANCEL_ASYNCHRONOUS, &oldtype);
\
- result = name params;
\
- pthread_setcanceltype (oldtype, NULL);
\
- return result;
\
+#define CANCELABLE_SYSCALL(res_type, name, param_list, params) \
+res_type __libc_##name param_list; \
+res_type \
+__attribute__ ((weak)) \
+name param_list
\
+{ \
+ res_type result; \
+ int oldtype; \
+ pthread_setcanceltype (PTHREAD_CANCEL_ASYNCHRONOUS, &oldtype); \
+ result = __libc_##name params; \
+ pthread_setcanceltype (oldtype, NULL); \
+ return result; \
}
linuxthreads.old machinery was calling __libc_foo in order to implement
"cancellation points" for function foo. It wasn't clear to me when I started
removing seemingly unused __libc_xxx aliases...
And then the compile broke, and another user "fixed" it by the above
patch (in reverse)...
So now the functions call themself recursively, and overflow the stack.
This needs to be either undone or fixed properly (using function pointer
table?).
I am guilty of this breakage. Not familiar enough with pthreads implementations
(and we are going to have THREE of those.... oh no).
Meanwhile, try unsetting LINUXTHREADS_OLD=y in your .config, does it work after
that?
--
vda
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
