Re: linuxthreads, signals and sigaltstack
>> I am trying to use signals and it is segfaulting in the linuxthreads code. I >> have not >> delved into it deeply yet but I think that self in __pthread_sighandler_rt() >> is NULL. I am >> guessing this is because I have setup a separate signal stack using >> sigaltstack and so the >> thread_self() function is unable to determine the thread. >> snip > > arm and linuxthread is not well tested in uclibc. > So I suggest try linuxtthreads.old or the nptl-branch. I tried linuxthreads.old first and hit a similar problem so moved to linuxthreads hoping there might be a fix. Looking at the code it seems like signal handling with a separate signal stack specified with sigaltstack is broken. The problem is that __pthread_sighandler_rt() is being called with the signal stack but it calls check_thread_self() which in turn calls thread_self() which determines which thread it is in by referring to the stack pointer. This does not work because the stack pointer points to the signal stack. Think instead __pthread_sighandler_rt() needs to use ucontext to get the stack pointer before the exception and then that needs to be used to to get the pthread_descr pointer. Can someone with more experience of the thread code comment? Does that sound right? The problem is that getting the stack pointer from the ucontext struct is platform specific I believe. Guess I'll try hacking something together for arm to begin with and see if my theory is right. Will. -- -------- Will Wagner will_wag...@carallon.com Development Manager Office Tel: +44 (0)20 7371 2032 Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
linuxthreads, signals and sigaltstack
Hi All, I am using uClibc 0.9.30 with linuxthreads on an arm target. I am trying to use signals and it is segfaulting in the linuxthreads code. I have not delved into it deeply yet but I think that self in __pthread_sighandler_rt() is NULL. I am guessing this is because I have setup a separate signal stack using sigaltstack and so the thread_self() function is unable to determine the thread. Before I start trying to debug this can anyone offer any insight on this? Does my theory sound plausible or have others managed to successfully do this? Thanks, Will -- Will Wagner will_wag...@carallon.com Development Manager Office Tel: +44 (0)20 7371 2032 Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
[Buildroot] PATCH: linuxthreads and arm compile fix
Doing a default config with linuxthreads and arm fails to compile due to missing headers. The attached patch adds the headers. After applying this patch it all seems to work. Will. -- Will Wagner will_wag...@carallon.com Development Manager Office Tel: +44 (0)20 7371 2032 Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA diff -uNprw a/libpthread/linuxthreads/sysdeps/arm/sysdep-cancel.h b/libpthread/linuxthreads/sysdeps/arm/sysdep-cancel.h --- a/libpthread/linuxthreads/sysdeps/arm/sysdep-cancel.h 1970-01-01 01:00:00.0 +0100 +++ b/libpthread/linuxthreads/sysdeps/arm/sysdep-cancel.h 2006-10-29 21:45:54.0 + @@ -0,0 +1,8 @@ +#include + +/* No multi-thread handling enabled. */ +#define SINGLE_THREAD_P (1) +#define RTLD_SINGLE_THREAD_P (1) +#define LIBC_CANCEL_ASYNC()0 /* Just a dummy value. */ +#define LIBC_CANCEL_RESET(val) ((void)(val)) /* Nothing, but evaluate it. */ +#define LIBC_CANCEL_HANDLED() /* Nothing. */ diff -uNprw a/libpthread/linuxthreads/sysdeps/arm/sysdep.h b/libpthread/linuxthreads/sysdeps/arm/sysdep.h --- a/libpthread/linuxthreads/sysdeps/arm/sysdep.h 1970-01-01 01:00:00.0 +0100 +++ b/libpthread/linuxthreads/sysdeps/arm/sysdep.h 2006-01-07 03:46:40.0 + @@ -0,0 +1,137 @@ +/* Generic asm macros used on many machines. + Copyright (C) 1991,92,93,96,98,2002,2003 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with the GNU C Library; if not, write to the Free + Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA + 02111-1307 USA. */ + +#ifndef C_LABEL + +/* Define a macro we can use to construct the asm name for a C symbol. */ +#ifdef NO_UNDERSCORES +#ifdef __STDC__ +#define C_LABEL(name) name##: +#else +#define C_LABEL(name) name/**/: +#endif +#else +#ifdef __STDC__ +#define C_LABEL(name) _##name##: +#else +#define C_LABEL(name) _/**/name/**/: +#endif +#endif + +#endif + +#ifdef __ASSEMBLER__ +/* Mark the end of function named SYM. This is used on some platforms + to generate correct debugging information. */ +#ifndef END +#define END(sym) +#endif + +#ifndef JUMPTARGET +#define JUMPTARGET(sym)sym +#endif + +/* Makros to generate eh_frame unwind information. */ +# ifdef HAVE_ASM_CFI_DIRECTIVES +# define cfi_startproc.cfi_startproc +# define cfi_endproc .cfi_endproc +# define cfi_def_cfa(reg, off).cfi_def_cfa reg, off +# define cfi_def_cfa_register(reg).cfi_def_cfa_register reg +# define cfi_def_cfa_offset(off) .cfi_def_cfa_offset off +# define cfi_adjust_cfa_offset(off) .cfi_adjust_cfa_offset off +# define cfi_offset(reg, off) .cfi_offset reg, off +# define cfi_rel_offset(reg, off) .cfi_rel_offset reg, off +# define cfi_register(r1, r2) .cfi_register r1, r2 +# define cfi_return_column(reg) .cfi_return_column reg +# define cfi_restore(reg) .cfi_restore reg +# define cfi_same_value(reg) .cfi_same_value reg +# define cfi_undefined(reg) .cfi_undefined reg +# define cfi_remember_state .cfi_remember_state +# define cfi_restore_state.cfi_restore_state +# define cfi_window_save .cfi_window_save +# else +# define cfi_startproc +# define cfi_endproc +# define cfi_def_cfa(reg, off) +# define cfi_def_cfa_register(reg) +# define cfi_def_cfa_offset(off) +# define cfi_adjust_cfa_offset(off) +# define cfi_offset(reg, off) +# define cfi_rel_offset(reg, off) +# define cfi_register(r1, r2) +# define cfi_return_column(reg) +# define cfi_restore(reg) +# define cfi_same_value(reg) +# define cfi_undefined(reg) +# define cfi_remember_state +# define cfi_restore_state +# define cfi_window_save +# endif + +#else /* ! ASSEMBLER */ +# ifdef HAVE_ASM_CFI_DIRECTIVES +# define CFI_STRINGIFY(Name) CFI_STRINGIFY2 (Name) +# define CFI_STRINGIFY2(Name) #Name +# define CFI_STARTPROC".cfi_startproc" +# define CFI_ENDPROC ".cfi_endproc" +# define CFI_DEF_CFA(reg, off)\ + ".cfi_de
x86 linuxthreads compile error
I have hit a compile error for linuxthreads for uClibc 0.9.29 make[3]: `conf' is up to date. CC ldso/ldso/ldso.oS In file included from ./libpthread/linuxthreads/sysdeps/i386/pt-machine.h:24, from ./libpthread/linuxthreads/sysdeps/i386/tls.h:23, from ./include/bits/uClibc_errno.h:35, from ./include/errno.h:62, from ./include/bits/syscalls.h:14, from ./include/sys/syscall.h:34, from ./ldso/ldso/i386/dl-syscalls.h:3, from ./ldso/include/dl-syscall.h:12, from ./ldso/include/ldso.h:36, from ldso/ldso/ldso.c:33: ./libpthread/linuxthreads/sysdeps/i386/i686/pt-machine.h:42: warning: C99 inline functions are not supported; using GNU89 ./libpthread/linuxthreads/sysdeps/i386/i686/pt-machine.h:42: warning: to disable this warning use -fgnu89-inline or the gnu_inline function attribute ./libpthread/linuxthreads/sysdeps/i386/i686/pt-machine.h:60: warning: C99 inline functions are not supported; using GNU89 In file included from ./libpthread/linuxthreads/sysdeps/i386/i686/pt-machine.h:73, from ./libpthread/linuxthreads/sysdeps/i386/pt-machine.h:24, from ./libpthread/linuxthreads/sysdeps/i386/tls.h:23, from ./include/bits/uClibc_errno.h:35, from ./include/errno.h:62, from ./include/bits/syscalls.h:14, from ./include/sys/syscall.h:34, from ./ldso/ldso/i386/dl-syscalls.h:3, from ./ldso/include/dl-syscall.h:12, from ./ldso/include/ldso.h:36, from ldso/ldso/ldso.c:33: ./libpthread/linuxthreads/sysdeps/i386/i686/../useldt.h:25:20: error: sysdep.h: No such file or directory make[1]: *** [ldso/ldso/ldso.oS] Error 1 make[1]: Leaving directory `/home/willw/martin/buildroot/toolchain_build_i686/uClibc-0.9.29' make: *** [/home/willw/martin/buildroot/toolchain_build_i686/uClibc-0.9.29/lib/libc.a] Error 2 I am using gcc 4.2.4 & binutils 2.18. I have attached my config Any suggestions on where I'm going wrong? Thanks, Will. -- -------- Will Wagner [EMAIL PROTECTED] Senior Project Engineer Office Tel: +44 (0)20 7371 2032 Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA .config Description: XML document ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
malloc question
Hi All, I am looking for some help on an issue I am having with malloc and running out of memory. I would like to get some notification in our application if a memory allocation fails with ENO_MEM when using malloc. Most of our application is C++ and so uses new where we can call set_new_handler so that we get a callback when we run out of memory. However a number of libs use malloc so I would like to implement similar functionality. I have looked at the source code for standard malloc and it doesn't appear to be any support for this. Can anyone suggest a good way to address this issue? Thanks, Will. -- Will Wagner [EMAIL PROTECTED] Senior Project Engineer Office Tel: +44 (0)20 7371 2032 Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: sysconf(_SC_MONOTONIC_CLOCK) problem
Thanks,
That patch seems to fix it.
Peter Kjellerstedt wrote:
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
>> Behalf Of Will Wagner
>> Sent: den 12 juni 2008 20:36
>> To: uclibc@uclibc.org
>> Subject: sysconf(_SC_MONOTONIC_CLOCK) problem
>>
>> Hello,
>>
>> I am using uclicb 0.9.29 on Arm built with buildroot
>>
>> I want to use monotonic clock support and to test that that
>> functionality exists I try the following bit of code:
>>
>> long x = sysconf(_SC_MONOTONIC_CLOCK);
>> bool hasMonotonic = x >= 200112L;
>>
>> However when I run this sysconf return -1.
>>
>> Looking at the code it appears this happens if __NR_clock_getres is not
>> defined. However looking at the kernel headers I think it is defined
>> as:
>>
>> #define __NR_clock_getres (__NR_SYSCALL_BASE+264)
>>
>> in unistd.h
>>
>> If I run this code:
>>
>> if (syscall(__NR_clock_getres, CLOCK_MONOTONIC, NULL) < 0)
>> {
>> printf("syscall failed %d", errno);
>> return 0;
>> }
>>
>> if (clock_getres(CLOCK_MONOTONIC, NULL) < 0)
>> {
>> printf("clock_getres failed %d", errno);
>> return 0;
>> }
>>
>> Then both calls succeed so the kernel supports this.
>>
>> From this I assume that uclibc is compiled as if __NR_clock_getres is
>> not defined. Does that sound right?
>>
>> I have looked for configuration options and can not find any for this.
>> How can I enable this?
>>
>>
>> Thanks,
>>
>> Will.
>
> The problem is that someone added the check for __NR_clock_getres
> after I added the support for _SC_MONOTONIC_CLOCK. Unfortunately
> they forgot to add an inclusion of sys/sycall.h which means
> __NR_clock_getres will never be defined...
>
> I just committed the following patch to the uClibc repository
> which should correct the situation:
>
> Index: libc/unistd/sysconf.c
> ===
> --- libc/unistd/sysconf.c (revision 18424)
> +++ libc/unistd/sysconf.c (working copy)
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #ifdef __UCLIBC_HAS_REGEX__
>
> //Peter
--
Will Wagner [EMAIL PROTECTED]
Senior Project Engineer Office Tel: +44 (0)20 7371 2032
Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
sysconf(_SC_MONOTONIC_CLOCK) problem
Hello,
I am using uclicb 0.9.29 on Arm built with buildroot
I want to use monotonic clock support and to test that that
functionality exists I try the following bit of code:
long x = sysconf(_SC_MONOTONIC_CLOCK);
bool hasMonotonic = x >= 200112L;
However when I run this sysconf return -1.
Looking at the code it appears this happens if __NR_clock_getres is not
defined. However looking at the kernel headers I think it is defined as:
#define __NR_clock_getres (__NR_SYSCALL_BASE+264)
in unistd.h
If I run this code:
if (syscall(__NR_clock_getres, CLOCK_MONOTONIC, NULL) < 0)
{
printf("syscall failed %d", errno);
return 0;
}
if (clock_getres(CLOCK_MONOTONIC, NULL) < 0)
{
printf("clock_getres failed %d", errno);
return 0;
}
Then both calls succeed so the kernel supports this.
From this I assume that uclibc is compiled as if __NR_clock_getres is
not defined. Does that sound right?
I have looked for configuration options and can not find any for this.
How can I enable this?
Thanks,
Will.
--
----
Will Wagner [EMAIL PROTECTED]
Senior Project Engineer Office Tel: +44 (0)20 7371 2032
Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: NPTL & ARM
Thanks for the reply. So I am trying to build uClibc through buildroot on arm with nptl. It fails with this error: ./libpthread/linuxthreads/sysdeps/arm/pt-machine.h:39: warning: C99 inline functions are not supported; using GNU89 ./libpthread/linuxthreads/sysdeps/arm/pt-machine.h:39: warning: to disable this warning use -fgnu89-inline or the gnu_inline function attribute In file included from libpthread/linuxthreads/sysdeps/pthread/errno-loc.c:22: ./libpthread/linuxthreads/internals.h:538: warning: C99 inline functions are not supported; using GNU89 libpthread/linuxthreads/sysdeps/pthread/errno-loc.c:23:27: error: sysdep-cancel.h: No such file or directory make[1]: *** [libpthread/linuxthreads/sysdeps/pthread/errno-loc.os] Error 1 make[1]: Leaving directory `/home/willw/buildroot/toolchain_build_arm/uClibc-0.9.29' make: *** [/home/willw/buildroot/toolchain_build_arm/uClibc-0.9.29/lib/libc.a] Error 2 Looking at uClibc (0.2.29) it does indeed seem that there is no arm folder in uClibc-0.9.29\libpthread\linuxthreads\sysdeps\unix\sysv\linux which is where sysdep-cancel.h appears it should be located for other architectures. Any help on fixing this would be great. Thanks, Will. Khem Raj wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Will Wagner wrote: >> Is NPTL supported under ARM? > > yes. > >> Have seen a few posts suggesting that it is not but also seen a patch >> from CodeSourcery that is a little old and I wondered if it had been >> applied? > > Not yet. This patch will be merged with rest of nptl work for other > arches which Steven has initiated. > >> Thanks, >> >> Will. > > > - -- > Khem Raj > MontaVista Software Inc. > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.7 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFHYVpJUjbQJxVzeZQRAkgbAKCHR13SgHOiOnl3JVJ25kjDEhz30ACggEIG > r5jV8Zdj9YQsDgGpezaFOtk= > =SLJZ > -END PGP SIGNATURE- -- Will Wagner [EMAIL PROTECTED] Senior Project Engineer Office Tel: +44 (0)20 7371 2032 Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
NPTL & ARM
Is NPTL supported under ARM? Have seen a few posts suggesting that it is not but also seen a patch from CodeSourcery that is a little old and I wondered if it had been applied? Thanks, Will. -- Will Wagner [EMAIL PROTECTED] Senior Project Engineer Office Tel: +44 (0)20 7371 2032 Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
termios2 support
Hello, I would like support for arbitrary baud rates with serial ports with through uclibc. I have looked at the uclibc code and there appear to be some support for this in kernel_termios.h but it is limited to alpha & powerpc. It also does not seem to use the kernel ioctl's TCGETS2 & TCSETS2 that are available with 2.6 Can anyone suggest the best way to extend x86 so that it has support for c_ispeed & c_ospeed in the termios structure? I believe that with the 2.6 kernel all architectures ktermios struct contains c_ispeed & c_ospeed and so it could be added generically. Is that correct? Looks like TCGETS2 & TCSETS2 are supported on both x86 and arm, is that right? Any help on this would be much appreciated. Will. -- ---- Will Wagner [EMAIL PROTECTED] Senior Project Engineer Office Tel: +44 (0)20 7371 2032 Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
