Re: NPTL branch temporarily broken
Carmelo AMOROSO wrote: > Hi Khem, > I'm seeing similar problem on sh4-nptl as happened to you as you told me > yesterday.. Something recently merged is causing issues. > I'm doing investigation and keep you all informed. > > Further I'm just writing a detailed report on current status of merge, > that I can say is almost complete (once figured out what is not > actually working ;-) ). > > I'm currently 100% focused on uclibc. > > Cheers, > Carmelo Khem, I think to have found what is causing problems on nptl branch (anyway I don't know why yet). The cause is the change merged from trunk in the file libc/sysdeps/linux/common/bits/sigset.h (rev 24243) that includes all changes occurred in the same file on trunk in rev 24183 / 24220 / 24221 by vda. Please may you try on ARM reverting that file and see if it helps. On sh4-nptl it's working better now Below the boot log on my box... not more PANIC on INIT even if it's blocking on udev This seems confirming my idea on signal handling changes. I'll try to merge on my private branch all changes that are already in the nptl-branch but thos on signal handling. - VFS: Mounted root (nfs filesystem) readonly. Freeing unused kernel memory: 132k freed INIT: version 2.86 booting Fast Starting Kernel event manager... Activating swap. Checking all file systems... fsck 1.39 (29-May-2006) Mounting local filesystems... Cleaning /tmp /var/run /var/lock. Setting up networking...done. Hostname: amorosoc. Setting up IP spoofing protection: rp_filter. Disable TCP/IP Explicit Congestion Notification: done. Configuring network interfaces: done. Starting portmap daemon: portmap. Cheers, Carmelo > ___ > uClibc mailing list > uClibc@uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
segfault with static programs that don't use stdio functions
Hi,
as the bug tracker is down, I try it here.
I discovered that all statically linked programs without stdio usage
segfault with uclibc 0.9.29 and later. Here is the example program I
used:
#include
#include
int main(void) {
write(1, "test\n", 5);
#ifdef USE_STDIO
puts("test2");
#endif
return 0;
}
I got this segfault with uclibc 0.9.29 and gcc 4.1 first. It happens on
i386, but not on big endian ARM. Here is the procedure how I tracked
this down with buildroot from latest git, using uclibc 0.9.30 and gcc
4.3.2:
This is the behaviour with stdio usage:
$ ./i386_build/staging/usr/bin/i386-linux-uclibc-gcc -o test -Wall -W
-g3 -O0 -static ~/test.c -DUSE_STDIO
$ ./test
test
test2
$
Without stdio usage:
$ ./i386_build/staging/usr/bin/i386-linux-uclibc-gcc -o test -Wall -W
-g3 -O0 -static ~/test.c
Segmentation fault
$
I built uclibc with DODEBUG enabled, and funnily segfault went away,
because it seems to be triggered with -O2 only. I changed the -O0 in
Rules.mak to -O2 to get debugging information and the segfault.
In gdb, I traced the bug to the invocation of _stdio_init():
$ gdb ./test
(gdb) break __uClibc_main.c:232
Breakpoint 1 at 0x8048311: file libc/misc/internals/__uClibc_main.c,
line 232.
(gdb) run
Starting program: /home/tkeitel/src/buildroot/test
Breakpoint 1, *__GI___uClibc_init () at
libc/misc/internals/__uClibc_main.c:233
233 _stdio_init();
(gdb) print _stdio_init
No symbol "_stdio_init" in current context.
(gdb) step
Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1 0x080483ca in __uClibc_main (main=0x8048188 , argc=1,
argv=0xff87dac4, app_init=0x8048094 <_init>, app_fini=0x8048c10
#<_fini>,
rtld_fini=0, stack_end=0xff87dabc)
at libc/misc/internals/__uClibc_main.c:318
#2 0x080480d1 in _start () at libc/sysdeps/linux/i386/crt1.S:128
So, _stdio_init() was called because the NULL check failed for some
reason:
if (likely(_stdio_init != NULL))
_stdio_init();
Without the likely(), the segfault also happens.
In uclibc 0.9.29, the weak _stdio_init declaration was extended by
attribute_hidden. I removed this attribute, and the segfault didn't
happen anymore. However, another segfault happend at the invocation of
_stdio_term(), which had the same problem with attribute_hidden.
Regards,
Tino
--
Tino Keitel
Software Engineer
Innominate Security Technologies AG
/protecting industrial networks/
Tel: +49.30.6392-3309
Fax: +49.30.6392-3307
Albert-Einstein-Str. 14
D-12489 Berlin
http://www.innominate.com/
Register Court: AG Charlottenburg, HRB 81603
Management Board: Dirk Seewald
Chairman of the Supervisory Board: Volker Bibelhausen
INNOMINATE IS MOVING. FROM 17.12.2008 OUR BUSINESS CONTACT DATA WILL BE
CHANGED:
Rudower Chaussee 13, 12489Berlin / Germany
tel: +49.30.921028-0 (head office)
tel: +49.30.921028-206 (personal extension)
fax: +49.30. 921028-020
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
where's the locale data?
so, uclibc-0.9.30 and the snapshot I found in the download dir both have this problem: (Makefile.in in the extras/locale directory of the tarball) LOCALE_DATA_FILENAME := uClibc-locale-2008-$(ARCH_NATIVE_BIT)-$(if $(ARCH_LITTLE_ENDIAN),el,eb).tgz locale_OUT)/$(LOCALE_DATA_FILENAME): ifeq ($(UCLIBC_DOWNLOAD_PREGENERATED_LOCALE_DATA),y) ( cd $(dir $@); $(WGET) http://www.uclibc.org/downloads/$(notdir $@) ) endif However, the only locale data in the downloads dir is http://www.uclibc.org/downloads/uClibc-locale-030818.tgz Can someone explain why this is completely wrong? Is it correct to simply change LOCALE_DATA_FILENAME to the correct filename (the only locale data filename)? signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: where's the locale data?
On Wed, Dec 10, 2008 at 10:21:32AM -0500, poly-p man wrote: >so, uclibc-0.9.30 and the snapshot I found in the download dir both have this >problem: The use of pregenerated locale data is not recommended. Rob promised to look into providing such data, not sure what the status is. > >(Makefile.in in the extras/locale directory of the tarball) >LOCALE_DATA_FILENAME := uClibc-locale-2008-$(ARCH_NATIVE_BIT)-$(if >$(ARCH_LITTLE_ENDIAN),el,eb).tgz > > > >locale_OUT)/$(LOCALE_DATA_FILENAME): >ifeq ($(UCLIBC_DOWNLOAD_PREGENERATED_LOCALE_DATA),y) > ( cd $(dir $@); $(WGET) http://www.uclibc.org/downloads/$(notdir $@) ) >endif > >However, the only locale data in the downloads dir is >http://www.uclibc.org/downloads/uClibc-locale-030818.tgz > >Can someone explain why this is completely wrong? This old locale data didn't work for (IIRC) mips32(eb) and others. > >Is it correct to simply change LOCALE_DATA_FILENAME to the correct filename >(the only locale data filename)? You could try. If you're lucky then it may work. In the end you're imho better off to generate those few locales that you really need, i.e. turn off using pregenerated locale data. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: NPTL branch temporarily broken
Carmelo AMOROSO wrote: > Carmelo AMOROSO wrote: >> Hi Khem, >> I'm seeing similar problem on sh4-nptl as happened to you as you told me >> yesterday.. Something recently merged is causing issues. >> I'm doing investigation and keep you all informed. >> >> Further I'm just writing a detailed report on current status of merge, >> that I can say is almost complete (once figured out what is not >> actually working ;-) ). >> >> I'm currently 100% focused on uclibc. >> >> Cheers, >> Carmelo > Khem, > I think to have found what is causing problems on nptl branch > (anyway I don't know why yet). > > The cause is the change merged from trunk in the file > libc/sysdeps/linux/common/bits/sigset.h (rev 24243) > > that includes all changes occurred in the same file on trunk > in rev 24183 / 24220 / 24221 by vda. > > Please may you try on ARM reverting that file > and see if it helps. On sh4-nptl it's working better now > Below the boot log on my box... not more PANIC on INIT > even if it's blocking on udev > > This seems confirming my idea on signal handling changes. > I'll try to merge on my private branch all changes that are already > in the nptl-branch but thos on signal handling. > > - > VFS: Mounted root (nfs filesystem) readonly. > Freeing unused kernel memory: 132k freed > INIT: version 2.86 booting > Fast Starting Kernel event manager... > Activating swap. > Checking all file systems... > fsck 1.39 (29-May-2006) > Mounting local filesystems... > Cleaning /tmp /var/run /var/lock. > Setting up networking...done. > Hostname: amorosoc. > Setting up IP spoofing protection: rp_filter. > Disable TCP/IP Explicit Congestion Notification: done. > Configuring network interfaces: done. > Starting portmap daemon: portmap. > > > Cheers, > Carmelo > Just an update: almost locally merged all the libc (including the libc/misc/internal) but the libc/signal and I have a still bootable uclibc-nptl system on sh4. I'll leave libc/signal as last. > >> ___ >> uClibc mailing list >> uClibc@uclibc.org >> http://busybox.net/cgi-bin/mailman/listinfo/uclibc >> > > ___ > uClibc mailing list > uClibc@uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: where's the locale data?
On Wednesday 10 December 2008 11:40:33 am you wrote: > On Wed, Dec 10, 2008 at 10:21:32AM -0500, poly-p man wrote: > >so, uclibc-0.9.30 and the snapshot I found in the download dir both have > > this problem: > > The use of pregenerated locale data is not recommended. > > Rob promised to look into providing such data, not sure what the > status is. > > >(Makefile.in in the extras/locale directory of the tarball) > >LOCALE_DATA_FILENAME := uClibc-locale-2008-$(ARCH_NATIVE_BIT)-$(if > >$(ARCH_LITTLE_ENDIAN),el,eb).tgz > > > > > > > >locale_OUT)/$(LOCALE_DATA_FILENAME): > >ifeq ($(UCLIBC_DOWNLOAD_PREGENERATED_LOCALE_DATA),y) > > ( cd $(dir $@); $(WGET) http://www.uclibc.org/downloads/$(notdir $@) ) > >endif > > > >However, the only locale data in the downloads dir is > >http://www.uclibc.org/downloads/uClibc-locale-030818.tgz > > > >Can someone explain why this is completely wrong? > > This old locale data didn't work for (IIRC) mips32(eb) and others. > > >Is it correct to simply change LOCALE_DATA_FILENAME to the correct > > filename (the only locale data filename)? > > You could try. If you're lucky then it may work. > In the end you're imho better off to generate those few locales that you > really need, i.e. turn off using pregenerated locale data. thanks for the reply - buildroot's default is to use pregenerated data, and the config's seem to suggest (some of them, at least) that it's a good idea.. If you are selective and only want locale data for a few particular │ │ locales, you can turn this option off. │ │ │ │ Mere mortals will answer Y and use the default set of pregenerated │ │ locale data, which supports 169 UTF-8 locales, and 144 locales for │ │ other codesets (for the complete list see extra/locale/LOCALES).│ │ │ │ Note that these pregenerated locales are sensitive to your │ │ target architecture (endianess, bitcount). │ │ │ │ Saying N here is recommended. I figured I was a mere mortal :P Time to generate some data... signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
mknod() broken with uclibc built with -O0
Hi,
the mknod() syscall is broken in my ulibc if I compile with -O0. I
discoverd this with uclibc 0.9.29 (not sure if 0.9.28 was also
affected) and gcc 4.1, and it still applies to the current git of
buildroot using uclibc 0.9.30 and gcc 4.3.2. The i386 architecture was
used.
For the test, I use the following command. The busybox is the one from
buildroot, and is therefore statically linked against the uclibc from
buildroot.
$ strace ./bin/busybox mknod foobar c 10 63
With -O0, strace looks like this:
mknod("foobar", S_IFCHR|037746400666, makedev(2314, 104767)) = -1
2314 translates to 0x90a , to this is the 10, prefixed with some
trash. 104767 translates to 1993f, so this is the 63, prefixed with
some trash. I think the same applies to the mode.
This is the raw strace output, gathered with strace -e raw=mknod:
mknod(0xffa31a31, 0xffa321b6, 0x19990a3f) = -1
With DODEBUG disabled in the uclibc config, and therefore compiled with
-O2, strace looks like this:
mknod("foobar", S_IFCHR|0666, makedev(10, 63)) = -1
So it looks like there is some mangling of the mknod() arguments in
uclibc, which breaks if compiled with -O0.
Regards,
Tino
--
Tino Keitel
Software Engineer
Innominate Security Technologies AG
/protecting industrial networks/
Tel: +49.30.6392-3309
Fax: +49.30.6392-3307
Albert-Einstein-Str. 14
D-12489 Berlin
http://www.innominate.com/
Register Court: AG Charlottenburg, HRB 81603
Management Board: Dirk Seewald
Chairman of the Supervisory Board: Volker Bibelhausen
INNOMINATE IS MOVING. FROM 17.12.2008 OUR BUSINESS CONTACT DATA WILL BE
CHANGED:
Rudower Chaussee 13, 12489Berlin / Germany
tel: +49.30.921028-0 (head office)
tel: +49.30.921028-206 (personal extension)
fax: +49.30. 921028-020
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: NPTL branch temporarily broken
On (10/12/08 17:52), Carmelo AMOROSO wrote: > Carmelo AMOROSO wrote: >> Carmelo AMOROSO wrote: >>> Hi Khem, >>> I'm seeing similar problem on sh4-nptl as happened to you as you told >>> me yesterday.. Something recently merged is causing issues. >>> I'm doing investigation and keep you all informed. >>> >>> Further I'm just writing a detailed report on current status of >>> merge, that I can say is almost complete (once figured out what is >>> not >>> actually working ;-) ). >>> >>> I'm currently 100% focused on uclibc. >>> >>> Cheers, >>> Carmelo >> Khem, >> I think to have found what is causing problems on nptl branch >> (anyway I don't know why yet). >> >> The cause is the change merged from trunk in the file >> libc/sysdeps/linux/common/bits/sigset.h (rev 24243) >> >> that includes all changes occurred in the same file on trunk >> in rev 24183 / 24220 / 24221 by vda. >> >> Please may you try on ARM reverting that file >> and see if it helps. On sh4-nptl it's working better now >> Below the boot log on my box... not more PANIC on INIT >> even if it's blocking on udev >> >> This seems confirming my idea on signal handling changes. >> I'll try to merge on my private branch all changes that are already >> in the nptl-branch but thos on signal handling. >> >> - >> VFS: Mounted root (nfs filesystem) readonly. >> Freeing unused kernel memory: 132k freed >> INIT: version 2.86 booting >> Fast Starting Kernel event manager... >> Activating swap. >> Checking all file systems... >> fsck 1.39 (29-May-2006) >> Mounting local filesystems... >> Cleaning /tmp /var/run /var/lock. >> Setting up networking...done. >> Hostname: amorosoc. >> Setting up IP spoofing protection: rp_filter. >> Disable TCP/IP Explicit Congestion Notification: done. >> Configuring network interfaces: done. >> Starting portmap daemon: portmap. >> >> >> Cheers, >> Carmelo >> > Just an update: almost locally merged all the libc (including the > libc/misc/internal) but the libc/signal and I have a still bootable > uclibc-nptl system on sh4. > I'll leave libc/signal as last. > OK I tried with this changes reverted(only uclibc rebuilt). Now I do not get the segfaults any more but it just hangs there. I will now try by rebuilding whole rfs. Thx -Khem >> >>> ___ >>> uClibc mailing list >>> uClibc@uclibc.org >>> http://busybox.net/cgi-bin/mailman/listinfo/uclibc >>> >> >> ___ >> uClibc mailing list >> uClibc@uclibc.org >> http://busybox.net/cgi-bin/mailman/listinfo/uclibc >> ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: __libc_xxx functions: what are they?
On Tuesday 09 December 2008 10:01, Bernhard Reutner-Fischer wrote:
> >> I do not see any explanation what are these?
> >>
> >> I do see that some of them are used from libpthread, but
> >> many are not (__libc_accept, __libc_getdomainname...).
> >>
> >> One purpose I might imagine if to make sure you are using
> >> libc implementation of a function, not something from
> >> another library...
> >>
> >IIRC, this is one of the reason.
> >
> >> Anyone knows better?
> >
> >probably these were intended to be used with
> >libc_hidden_proto/defs for avoing PLT entries
> >when called from within libc itself... but now
> >it should be the case any more.
>
> All __libc_*() should be removed or, where needed, at least hidden.
>
> We need some few functions for "intimite" users such as libpthread (and
> perhaps librt). For these we will (resp NPTL probably already has or
> should have) add a dispatcher struct (think GLRO et al).
Why they can't use normal functions? [education time!]
Anyway. I found this post in glibc:
http://sources.redhat.com/ml/libc-hacker/2004-05/msg1.html
2004-05-01 Jakub Jelinek <[EMAIL PROTECTED]>
* posix/Versions (libc): Remove __libc_wait, __libc_waitpid,
__libc_pause, __libc_nanosleep, __libc_pread, __libc_pread64,
__libc_pwrite64, __waitid and __pselect @@GLIBC_PRIVATE.
* stdlib/Versions (libc): Remove __on_exit@@GLIBC_PRIVATE.
* sysdeps/unix/sysv/linux/Versions (libc): Remove
__libc_sigaction@@GLIBC_PRIVATE.
* sysdeps/unix/sysv/linux/x86_64/Versions (libc): Remove
__modify_ldt@@GLIBC_PRIVATE.
* socket/Versions (libc): Remove __libc_accept, __libc_send,
__libc_recvfrom, __libc_recvmsg, __libc_sendmsg, __libc_recv,
__libc_sendto and __libc_connect @@GLIBC_PRIVATE.
* stdio-common/Versions (libc): Remove
_itoa_upper_digits@@GLIBC_PRIVATE.
* resolv/Versions (libresolv): Remove __ns_samename@@GLIBC_PRIVATE.
* misc/Versions (libc): Remove __libc_fsync, __libc_msync,
__libc_readv and __libc_writev @@GLIBC_PRIVATE.
* termios/Versions (libc): Remove __libc_tcdrain@@GLIBC_PRIVATE.
* io/Versions (libc): Remove __libc_open, __libc_close, __libc_read,
__libc_write, __libc_lseek, __libc_fcntl, __libc_open64 and
__libc_lseek64 @@GLIBC_PRIVATE.
linuxthreads/
* Versions (libc): Add __on_exit and __libc_sigaction.
nptl/
* Versions (libpthread): Remove
__pthread_cleanup_upto@@GLIBC_PRIVATE.
nptl_db/
* thread_dbP.h (LOG): Use write instead of __libc_write.
linuxthreads_db/
* thread_dbP.h (LOG): Use write instead of __libc_write.
so I decided it's fairly safe to remove them.
I did not remove:
__libc_sigaction, __libc_p{read,write}[64]
way too many places to touch, decided to do it separately
__modify_ldt - !!?? only extern exists, but not the body?!
__ns_samename - it's a #define for ns_samename
__pthread_cleanup_upto - seems to be internal func
The removal patch is attached, maybe it is useful
for you Carmelo.
Yell at me if something broke.
If any fucntions need to be restored back, we need
to DOCUMENT why.
--
vda
6.patch.gz
Description: GNU Zip compressed data
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
features.h and libc-XXX.h files
Hi,
I played a bit with installed uclibc headers
(result of make install) and I noticed a few things:
features.h:
/* uClibc does not support *at interfaces. */
#undef _ATFILE_SOURCE
#undef __USE_ATFILE
Is this still frue? I saw some patches flying around...
Looks like _LIB define actually means "at libc build time"
(wow, a textbook example of a bad name).
#ifdef _LIBC
# include
#endif
That's what I used UCLIBC_INTERNAL for (because I didn't know
about/_LIBC), but UCLIBC_INTERNAL also is unifdef'ed
out of installed headers. Are we better to also unifdef _LIBC?
And lastly, libc-internal.h and libc-symbols.h seem to be
of interest only to uclibc itself. These are also the only
files with pattern libc-.h. Should we exclude all such files?
This would be useful for other internal things too.
For one, I plan to add some optimized assembly
for inlined memsets etc, and I don't want it to spill over
into installed headers. libc-string-$ARCH.h would be a good place...
(OTOH:
hmm maybe i _should_ make it appear in installed headers?
User program:
#define UCLIBC_GIVE_ME_GOOD_STUFF
#include // your memset now a clever macro (maybe)
)
Example of changes in installed headers by attached patch:
--- /usr/srcdevel/uclibc/fix/uClibc.t6/!INSTALL/i386/usr/include/features.h
Thu Dec 11 00:36:36 2008
+++ !INSTALL/i386/usr/include/features.hThu Dec 11 01:05:33 2008
@@ -410,9 +410,6 @@
#undef _ATFILE_SOURCE
#undef __USE_ATFILE
-#ifdef _LIBC
-# include
-#endif
/* Some people like to build up uClibc with *-elf toolchains, so
* a little grease here until we drop '#ifdef __linux__' checks
Only in /usr/srcdevel/uclibc/fix/uClibc.t6/!INSTALL:
i386/usr/include/libc-symbols.h
--- /usr/srcdevel/uclibc/fix/uClibc.t6/!INSTALL/i386/usr/include/malloc.h
Thu Dec 11 00:36:36 2008
+++ !INSTALL/i386/usr/include/malloc.h Thu Dec 11 01:05:33 2008
@@ -51,11 +51,7 @@
# define __malloc_ptr_t char *
#endif
-#ifdef _LIBC
-/* Used by GNU libc internals. */
-# define __malloc_size_t size_t
-# define __malloc_ptrdiff_t ptrdiff_t
-#elif !defined __attribute_malloc__
+#if !defined __attribute_malloc__
# define __attribute_malloc__
#endif
The patch itself is below. Is it ok?
--
vda
diff -d -urpN uClibc.6/extra/scripts/install_headers.sh
uClibc.7/extra/scripts/install_headers.sh
--- uClibc.6/extra/scripts/install_headers.sh 2008-11-29 16:37:45.0
+0100
+++ uClibc.7/extra/scripts/install_headers.sh 2008-12-11 01:09:20.0
+0100
@@ -41,13 +41,17 @@ IFS=''
while read -r filename; do
if test -d "$1/$filename"; then
mkdir -p "$2/$filename" 2>/dev/null
- else
- # NB: unifdef exits with 1 if output is not
- # exactly the same as input. That's ok.
- # Do not abort the script if unifdef "fails"!
- "$top_builddir/extra/scripts/unifdef" -UUCLIBC_INTERNAL
"$1/$filename" \
- | sed -e
'/^\(rtld\|lib\(c\|m\|resolv\|dl\|intl\|rt\|nsl\|util\|crypt\|pthread\)\)_hidden_proto[
]*([a-zA-Z0-9_]*)$/d' >"$2/$filename"
+ continue
+ fi
+ if test x"${filename##libc-*.h}" = x""; then
+ # Do not install libc-.h files
+ continue
fi
+ # NB: unifdef exits with 1 if output is not
+ # exactly the same as input. That's ok.
+ # Do not abort the script if unifdef "fails"!
+ "$top_builddir/extra/scripts/unifdef" -UUCLIBC_INTERNAL -U_LIBC
"$1/$filename" \
+ | sed -e
'/^\(rtld\|lib\(c\|m\|resolv\|dl\|intl\|rt\|nsl\|util\|crypt\|pthread\)\)_hidden_proto[
]*([a-zA-Z0-9_]*)$/d' >"$2/$filename"
done
)
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: NPTL branch temporarily broken
On Wednesday 10 December 2008 10:06, Carmelo AMOROSO wrote:
> Carmelo AMOROSO wrote:
> > Hi Khem,
> > I'm seeing similar problem on sh4-nptl as happened to you as you told me
> > yesterday.. Something recently merged is causing issues.
> > I'm doing investigation and keep you all informed.
> >
> > Further I'm just writing a detailed report on current status of merge,
> > that I can say is almost complete (once figured out what is not
> > actually working ;-) ).
> >
> > I'm currently 100% focused on uclibc.
> >
> > Cheers,
> > Carmelo
> Khem,
> I think to have found what is causing problems on nptl branch
> (anyway I don't know why yet).
>
> The cause is the change merged from trunk in the file
> libc/sysdeps/linux/common/bits/sigset.h (rev 24243)
>
> that includes all changes occurred in the same file on trunk
> in rev 24183 / 24220 / 24221 by vda.
>
> Please may you try on ARM reverting that file
> and see if it helps. On sh4-nptl it's working better now
> Below the boot log on my box... not more PANIC on INIT
> even if it's blocking on udev
>
> This seems confirming my idea on signal handling changes.
> I'll try to merge on my private branch all changes that are already
> in the nptl-branch but thos on signal handling.
The change is that sigset_t is not 1024 bits, but 64 bits
on almost all architectures. Only MIPS has 128.
This affects sigaction and sigprocmask, but they already
are translating libc struct sigaction / sigset_t to kernel's.
With this change sigset_t actually should match kernel one,
albeit struct sigaction is still different a bit.
Anyway, the symptom of breakage would be, for example,
in libc/sysdeps/linux/arm/sigaction.c:
int __libc_sigaction (int sig, const struct sigaction *act, struct sigaction
*oact)
{
int result;
struct kernel_sigaction kact, koact;
enum {
SIGSET_MIN_SIZE = sizeof(kact.sa_mask) < sizeof(act->sa_mask)
? sizeof(kact.sa_mask) : sizeof(act->sa_mask)
};
*** first thing to check is whether sizeof(kact.sa_mask) ==
sizeof(act->sa_mask).
I tried to make it work even if it does not, but it's always better if they
match.
add line
struct BUG { int bug[sizeof(kact.sa_mask) == sizeof(act->sa_mask) ? 1 : -1]; };
and if compile fails, sizeof's are not ==.
Let me know that.
if (act) {
kact.k_sa_handler = act->sa_handler;
memcpy (&kact.sa_mask, &act->sa_mask, SIGSET_MIN_SIZE);
kact.sa_flags = act->sa_flags;
# ifdef HAVE_SA_RESTORER
if (kact.sa_flags & SA_RESTORER) {
kact.sa_restorer = act->sa_restorer;
} else {
kact.sa_restorer = choose_restorer (kact.sa_flags);
kact.sa_flags |= SA_RESTORER;
}
# endif
}
*** next:
/* NB: kernel (as of 2.6.25) will return EINVAL
* if sizeof(kact.sa_mask) does not match kernel's sizeof(sigset_t) */
result = __syscall_rt_sigaction(sig,
act ? __ptrvalue (&kact) : NULL,
oact ? __ptrvalue (&koact) : NULL,
sizeof(kact.sa_mask));
Basically, if it throws EINVAL, always, then sizeof(kact.sa_mask) is botched.
(Kernel simply compares it with constant, it must be correct to work,
no "greater or equal" slack there).
I think adding if (errno == EINVAL) write(2, "EINVAL!\n", 8);
will tell you whether it happens.
sigprocmask is simpler:
int sigprocmask(int how, const sigset_t * set, sigset_t * oldset)
{
if (set &&
...
) {
__set_errno(EINVAL);
return -1;
}
return __rt_sigprocmask(how, set, oldset, _NSIG / 8);
Again, _NSIG / 8 must be correct here, or it will fail always.
Hope this helps
--
vda
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: segfault with static programs that don't use stdio functions
On Wednesday 10 December 2008 15:57, Tino Keitel wrote: > So, _stdio_init() was called because the NULL check failed for some > reason: > > if (likely(_stdio_init != NULL)) > _stdio_init(); > > Without the likely(), the segfault also happens. gcc thinks that function address is never NULL. Check assembly. I bet condition check got optimized away. > In uclibc 0.9.29, the weak _stdio_init declaration was extended by > attribute_hidden. I removed this attribute, and the segfault didn't > happen anymore. However, another segfault happend at the invocation of > _stdio_term(), which had the same problem with attribute_hidden. We probably need to add some idiotic hack like #define IS_FPTR_NULL(p) (((long)p ^ 0x1) == 1L) which actually WILL generate xor insn!! Gaaack... or even #define IS_FPTR_NULL(p) (((long)p ^ 0x1) - 1 == 0) to confuse gcc more... -- vda ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: mknod() broken with uclibc built with -O0
On Wednesday 10 December 2008 18:34, Tino Keitel wrote:
> Hi,
>
> the mknod() syscall is broken in my ulibc if I compile with -O0. I
> discoverd this with uclibc 0.9.29 (not sure if 0.9.28 was also
> affected) and gcc 4.1, and it still applies to the current git of
> buildroot using uclibc 0.9.30 and gcc 4.3.2. The i386 architecture was
> used.
>
> For the test, I use the following command. The busybox is the one from
> buildroot, and is therefore statically linked against the uclibc from
> buildroot.
>
> $ strace ./bin/busybox mknod foobar c 10 63
>
> With -O0, strace looks like this:
>
> mknod("foobar", S_IFCHR|037746400666, makedev(2314, 104767)) = -1
Can you try smaller test program? A-la
#include
int main() {
mknod("foobar", 0755, makedev(10,63));
return 0;
}
If this works, add more stuff until it breaks.
Tell us what broke it. Show gcc -On -S results.
--
vda
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: segfault with static programs that don't use stdio functions
On (11/12/08 01:57), Denys Vlasenko wrote: > On Wednesday 10 December 2008 15:57, Tino Keitel wrote: > > So, _stdio_init() was called because the NULL check failed for some > > reason: > > > > if (likely(_stdio_init != NULL)) > > _stdio_init(); > > > > Without the likely(), the segfault also happens. > > gcc thinks that function address is never NULL. Check assembly. > I bet condition check got optimized away. try -fno-delete-null-pointer-checks for experimenting. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Fix Thumb-2 PIEs
On Tuesday 09 December 2008 22:00, Rob Landley wrote: > Right now, there are still two "old" linuxthreads branches in uClibc, and as > far as I can tell we'll be supporting them in perpetuity. (For a definition > of "support" that involves leaving them alone unless somebody complains.) We need to stop doing that, though. We have "ond" and "new" vfprintf, "old" and "new" regex, "old" and "new" threads, "old" and "new" fnmatch. Let's just decide on something, and disable things which are really "old". Because currently, I need telepathic powers to figure out which regex to choose: Sometimes "old" is actually old and better be dropped, other times "old" is actually "stable and recommended", and "new" is "work in progress, and maybe developer was hit by the bus, nobody knows". For one, I do not know what vfprintf or regex to choose, I use rand(). But users are even less likely than we to know what to choose. We, as developers, need to help them. It's not like disabling or even rm'ing one or the other is irreversible. It all will still be in a history. Just IMHO. Bernhard, I guess it's up to you to decide this. -- vda ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: segfault with static programs that don't use stdio functions
On Wednesday 10 December 2008 08:57:30 Tino Keitel wrote:
> Hi,
>
> as the bug tracker is down, I try it here.
>
> I discovered that all statically linked programs without stdio usage
> segfault with uclibc 0.9.29 and later. Here is the example program I
...
> I got this segfault with uclibc 0.9.29 and gcc 4.1 first. It happens on
> i386, but not on big endian ARM. Here is the procedure how I tracked
> this down with buildroot from latest git, using uclibc 0.9.30 and gcc
> 4.3.2:
I haven't seen it in 0.9.30, but then I'm using gcc 4.1 not 4.3.
The patch I used to fix it for 0.9.29 with 4.1 is attached. (The gcc
./configure step creates a "void main(void) {}" and compiles and runs it as a
sanity test for the compiler, which segfaulted with stock uClibc 0.9.29 but
works fine for me out of the box with 0.9.30.)
Rob
From [EMAIL PROTECTED] Thu Jul 17 18:36:26 2008
I noticed in your July
13th blog entry that you've hit the uClibc static segfaulting bug. I'm
really surprised no one fixed this before because it was the first thing
I did with my first uClibc toolchain. 'int main(){return 0;}' is like
the Ur-loWorld of toolchainery, especially when one is concerned with
static-binary-byte-bloat which seems to be an obsession of uClibbers.
Anyway, that was about 4 days ago so you've probably fixed it by now,
but just in case you haven't I'm passing along my patch for it. (Not to
worry, I haven't released anything yet so there's no GPL violation, and
I'm hereby putting my patch into the public domain in case you want to
submit it to uClibc)
diff -ru uClibc-0.9.29-old/libc/misc/internals/__uClibc_main.c uClibc-0.9.29/libc/misc/internals/__uClibc_main.c
--- uClibc-0.9.29-old/libc/misc/internals/__uClibc_main.c 2007-01-11 16:39:13.0 -0600
+++ uClibc-0.9.29/libc/misc/internals/__uClibc_main.c 2007-09-15 07:13:18.0 -0500
@@ -79,13 +79,17 @@
* Prototypes.
*/
extern void weak_function _stdio_init(void) attribute_hidden;
+static void __weakstub (void) { return; }
+weak_alias (__weakstub, _stdio_init)
extern int *weak_const_function __errno_location(void);
extern int *weak_const_function __h_errno_location(void);
#ifdef __UCLIBC_HAS_LOCALE__
extern void weak_function _locale_init(void) attribute_hidden;
+weak_alias (__weakstub, _locale_init)
#endif
#ifdef __UCLIBC_HAS_THREADS__
extern void weak_function __pthread_initialize_minimal(void);
+weak_alias (__weakstub, __pthread_initialize_minimal)
#endif
/* If __UCLIBC_FORMAT_SHARED_FLAT__, all array initialisation and finalisation
@@ -198,8 +202,7 @@
* __pthread_initialize_minimal so we can use pthread_locks
* whenever they are needed.
*/
-if (likely(__pthread_initialize_minimal!=NULL))
- __pthread_initialize_minimal();
+__pthread_initialize_minimal();
#endif
#ifndef SHARED
@@ -222,8 +225,7 @@
#ifdef __UCLIBC_HAS_LOCALE__
/* Initialize the global locale structure. */
-if (likely(_locale_init!=NULL))
- _locale_init();
+_locale_init();
#endif
/*
@@ -232,8 +234,7 @@
* Thus we get a nice size savings because the stdio functions
* won't be pulled into the final static binary unless used.
*/
-if (likely(_stdio_init != NULL))
- _stdio_init();
+_stdio_init();
}
libc_hidden_def(__uClibc_init)
diff -ru uClibc-0.9.29-old/libc/stdlib/_atexit.c uClibc-0.9.29/libc/stdlib/_atexit.c
--- uClibc-0.9.29-old/libc/stdlib/_atexit.c 2007-05-04 09:13:17.0 -0500
+++ uClibc-0.9.29/libc/stdlib/_atexit.c 2007-09-15 07:14:47.0 -0500
@@ -306,6 +306,8 @@
#ifdef L_exit
extern void weak_function _stdio_term(void) attribute_hidden;
+static void __weakstub (void) { return; }
+weak_alias (__weakstub, _stdio_term)
attribute_hidden void (*__exit_cleanup) (int) = 0;
__UCLIBC_MUTEX_INIT(__atexit_lock, PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP);
@@ -330,8 +332,7 @@
* this will attempt to commit all buffered writes. It may also
* unbuffer all writable files, or close them outright.
* Check the stdio routines for details. */
- if (_stdio_term)
- _stdio_term();
+ _stdio_term();
_exit(rv);
}
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: where's the locale data?
On Wednesday 10 December 2008 10:40:33 Bernhard Reutner-Fischer wrote: > On Wed, Dec 10, 2008 at 10:21:32AM -0500, poly-p man wrote: > >so, uclibc-0.9.30 and the snapshot I found in the download dir both have > > this problem: > > The use of pregenerated locale data is not recommended. > > Rob promised to look into providing such data, not sure what the > status is. My bad, I got distracted. I'll try to poke at that later tonight. Rob ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Fix Thumb-2 PIEs
On Wednesday 10 December 2008 19:17:53 Denys Vlasenko wrote: > On Tuesday 09 December 2008 22:00, Rob Landley wrote: > > Right now, there are still two "old" linuxthreads branches in uClibc, and > > as far as I can tell we'll be supporting them in perpetuity. (For a > > definition of "support" that involves leaving them alone unless somebody > > complains.) > > We need to stop doing that, though. I tried arguing that a couple months back. Good luck. :) > We have "ond" and "new" vfprintf, "old" and "new" regex, > "old" and "new" threads, "old" and "new" fnmatch. > > Let's just decide on something, and disable things which are > really "old". Because currently, I need telepathic powers > to figure out which regex to choose: > > Sometimes "old" is actually old and better be dropped, > other times "old" is actually "stable and recommended", > and "new" is "work in progress, and maybe developer was hit > by the bus, nobody knows". For one, I do not know > what vfprintf or regex to choose, I use rand(). Once you have multiple implementations going in parallel that don't share code, it's an AMAZING PAIN to stop doing it again because somebody somewhere will fight to keep the one they're using. (The multi-shell situation in busybox is similar.) The thing is, this sort of thing fragments your tester base. Each version has different capabilities and different bugs. Size optimizations applied to one aren't applicable to another. Work put in to 1 of 3 implementations is only 1/3 as effective... > But users are even less likely than we to know what to choose. > We, as developers, need to help them. > > It's not like disabling or even rm'ing one or the other > is irreversible. It all will still be in a history. > > Just IMHO. Bernhard, I guess it's up to you to decide this. I plead the fifth. Rob ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Weird build dependencies.
So I'm trying to do:
make -j 3 install install_utils
And it's not working.
I added "all" as a dependency on "utils:" in the top level Makefile.in,
because make utils wants to link against the uClibc headers/libraries we just
built so it helps if they're there. (make hostutils is the one that builds
against the host system's headers and libraries. I'm pretty sure it's linking
'em out of the build directories and not out of the install directories, so
depending on "all" rather than "install" sounds closer to correct.)
Now what it's doing is this:
CC lib/interp.os
lib/interp.c:5: error: redefinition of '__dl_ldso__'
lib/interp.c:4: error: previous definition of '__dl_ldso__' was here
make[2]: *** [lib/interp.os] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [../lib/libc.so.0] Error 2
make: *** [utils] Error 2
Exiting due to errors
Exiting due to errors
And the reason it's doing that is that lib/interp.c looks like this:
/* Force shared libraries to know about the correct library loader */
#include
#include
const char __dl_ldso__[] __attribute__ ((section (".interp"))) ="/lib/ld-
uClibc.so.0";
const char __dl_ldso__[] __attribute__ ((section (".interp"))) ="/lib/ld-
uClibc.so.0";
Because the chunk of Makerules responsible for creating that file looks like
this:
$(top_builddir)lib/interp.c: | $(sub_headers)
$(Q)$(INSTALL) -d $(dir $@)
$(Q)echo "/* Force shared libraries to know about the correct library
loader */" > $@
$(Q)echo "#include " >> $@
$(Q)echo "const char __dl_ldso__[] __attribute__ ((section " \
"(\".interp\"))) =\""$(SHARED_LIB_LOADER_PREFIX)/$(UCLIBC_LDSO)"\";"
>> $@
So if that gets called twice by two of the -j threads, it creates the file
once and then appends the lines to it twice. Which seems just _weird_ to me.
I thought I'd ping the list in case somebody knows what this was trying to
accomplish and why it's the way it is and so on. I can randomly flail away at
the dependencies here but I'd appreciate it if somebody who _understood_ this
could take a look at it...
Thanks,
Rob
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Weird build dependencies.
On Wednesday 10 December 2008 22:09:26 Rob Landley wrote: > I thought I'd ping the list in case somebody knows what this was trying to > accomplish and why it's the way it is and so on. I can randomly flail away > at the dependencies here but I'd appreciate it if somebody who _understood_ > this could take a look at it... Specifically, I don't understand svn 22789, and to a lesser extent 14102 and 12480. I also don't understand why Rules.mak has lib/interp.os but makerules has lib/interp.c. Rob ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
