Re: pthread_create fails on a device with 16MB RAM
On 28/01/11 00:39, Alexander Gordeev wrote: Hi! I have a problem with pthread_create on a device with only 16MB RAM. strace shows this: old_mmap(NULL, 8388608, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory) instead of (what I obtained on another device with 32MB RAM): old_mmap(NULL, 8388608, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 2143089904, 0x2b985918) = 0x2bc6b000 mprotect(0x2bc6b000, 4096, PROT_NONE) = 0 clone(child_stack=0x2c46a3b0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x2c46a6f8, tls=0x2c471960, child_tidptr=0) = 1394 which is quite reasonable because 8388608 is greater than half the amount of available physical memory which AFAIK is a limit for memory allocations normally. When I did echo 1 /proc/sys/vm/overcommit_memory everything worked like a charm (because this limit was disabled). How can I tune uClibc to not request so much memory on pthread_create? This occurs because the default maximum stack size is usually 8MB (check using ulimit -s or -a at a shell prompt). You have a number of options to change this: 1. Change the default maximum stack size. This can be done in a shell by using ulimit -s or by using the setrlimit() C lib function call with RLIMIT_STACK option. You can set an explicit value (16 kiB min) or if you set it to RLIM_INFINITY then a architecture-dependent default size will be used (in NPTL this is defined in sysdeps/arch/pthreaddef.h in ARCH_STACK_DEFAULT_SIZE in linuxthreads the header file is pt-machine.h) 2. Allocate your own stack memory, insert into to a thread attribute structure using pthread_attr_setstack() and use that when creating the thread with pthread_create() 3. Patch the C library to use a more appropriate default rather than calling getrlimit(RLIMIT_STACK)! Cheers, Carl ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: svn commit: trunk/uClibc/ldso/ldso/sh
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Mundt wrote: On Sat, Jan 12, 2008 at 07:06:02PM +0100, Carmelo Amoroso wrote: Mike Frysinger wrote: On Saturday 12 January 2008, [EMAIL PROTECTED] wrote: Author: carmelo Date: 2008-01-12 00:20:18 -0800 (Sat, 12 Jan 2008) New Revision: 20848 Log: Make sh4 build works again adding a temporary work-around iby redefining __always_inline to inline until gcc 4.x.x will get fixed. Modified: trunk/uClibc/ldso/ldso/sh/dl-syscalls.h +#warning !!! __always_inline redefined waiting for the fixed gcc +#ifdef __always_inline +#undef __always_inline +#define __always_inline inline +#endif shouldnt you leverage __GNUC_PREREQ(4, 0) ? and add information about what version of gcc is actually broken ? -mike Hi Mike, done. I'm assuming the problem is with gcc 4.1 and later. If your new compiler is sane enough to define __GNUC_STM_RELEASE__ as was discussed before, it might be worth conditionalizing on that also. We already do that in the kernel for some other cases.. Yes, the new compiler does (and we will continue to in future, although we expect to push back our changes to gcc). We got burnt with that one before. Carl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHjKtTsOYe+9JwoiQRAtq3AKCb+TDnsaYSrsHdHO9qZdtsxllO8QCfWcHz V1meZGkqSOHcXUqjPkBMGlU= =3XcY -END PGP SIGNATURE- ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: dl_iterate_phdr missing in libc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Carmelo Amoroso wrote: Mike Frysinger wrote: On Friday 11 January 2008, Carmelo AMOROSO wrote: I'm facing a problem when statically linking an app with sh4-linux-uclibc-g++ caused by the missing symbol dl_iterate_phdr as below: sh4-linux-uclibc-g++ -static main.c /opt/STM/STLinux-2.3/devkit/sh4_uclibc/lib/gcc/sh4-linux-uclibc/4.2.1/libgc c_eh.a(unwind-dw2-fde-glibc.o): In function `_Unwind_Find_FDE': /home/macaroni/users/products/stm2.3/build/packages/stm-cross-gcc-sh4_uclib c/BUILD/gcc-4.2.1/objdir/gcc/../../gcc/unwind-dw2-fde-glibc.c:430: undefined reference to `dl_iterate_phdr' static is the devil ;) Hi Mike, yes, but it seems a lot of people in embedded world prefer it, likely they have concerns on performance. I think the reason is that traditionally embedded boxes only contained a single monolithic application (and in the past not even an OS). i.e. there are no root file system utilities like ls, etc. and the application replaces the init process. This was to reduce system complexity and keep the software as small as possible (FLASH memory is relatively expensive). Except for really basic systems, even embedded boxes these days are becoming too complicated for such a model so this approach is dying out... Besides, I think that the performance difference between dynamic and static on SH4 will be tiny given its 16 bit instruction set (load/stores via addresses in registers, branch instructions are all relative, etc.) - - only the dynamic loader would cause a small overhead on startup and for a simple application this is not worth the problems! Carl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHizWYsOYe+9JwoiQRAuKwAJ4je7fEKUqamaktpDpdzC+TecvxlwCeI4nR UgbBLq3s/j62nM6k6PKNOJc= =9ySw -END PGP SIGNATURE- ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Now I'm curious...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 latest SH4 uClibc public release in RPM source package: http://www.stlinux.com/pub/stlinux/2.3ear/SRPMS/stlinux23ear-target-uclibc-nptl-0.9.29-23.src.rpm There is also an SH4 uclibc toolchain and user-space applications (e.g. busybox). Binary versions of the RPMs are on same server. We'll hopefully release an entire uClibc-NPTL distribution for SH4 in the next few weeks. Carl Steven J. Hill wrote: On Wed, Sep 05, 2007 at 02:52:11PM +0200, Christian MICHON wrote: so, the NPTL stuff is ready... My branch contains a fully working NPTL for the MIPS architecture only. I have patches from CodeSourcery for ARM and ST Microelectronics for SuperH 4. Those are the only three architectures supported at this time. is it fully available somewhere now or it cannot be released ? The MIPS stuff is the 'uClibc-NPTL' branch. ARM and SH4 are in my mail folders somewhere if you are interested. -Steve ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG3shQsOYe+9JwoiQRAkt0AJ9v1jX/PyhLQ/x7aLjCSOWYC3wTYwCfaH3i wAMiLmzehyxGzX8xqY0aRew= =Wqna -END PGP SIGNATURE- ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
