| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Peter S. Mazinger <ps.m@gmx.net>
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
|
|
Signed-off-by: Peter S. Mazinger <ps.m@gmx.net>
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
|
|
Signed-off-by: Peter S. Mazinger <ps.m@gmx.net>
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
|
|
use cancellation (with two 'l') uniformly.
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
|
|
Because the nommu address space is flat, and the application stack can
literally be located anywhere, we cannot rely on the assumptions that the
mmu port gets away with. Namely, that the first thread's stack lives at
the top of memory and nothing will be created above it.
Currently, the code rounds the current stack up a page and sets that as
the "top" of the stack, and then marks the "bottom" of the stack as "1".
Then as new threads are created, this assumption is further refined by
slowly backing off the "bottom" when a new stack is created within the
range of the initial stack.
Simple ascii example (tid0 is the initial thread):
1 thread:
[bos tid0 stack tos]
2 threads:
[ tid0 stack ]
[tid1 stack]
3 threads:
[ tid0 stack ]
[tid1 stack]
[tid2 stack]
As you can kind of see, this algorithm operates on one basic assumption:
the initial top of stack calculation is the absolute top of the stack.
While this assumption was fairly safe in the original nommu days of yore
where the only file format was FLAT (which defaults to a 4KiB stack --
exactly 1 page), and memory was fairly tight, we can see that this falls
apart pretty quickly as soon as the initial stack is larger than a page.
The issue that crops up now is simple to hit: start an application with
an 8KiB stack, execute some functions that put pressure on the stack so
that it exceeds 4KiB, then start up some threads. The initial tos will
be rounded up by a page, but this is actually the middle of the stack.
Now when the initial thread returns from its functions (thus unwinding
the stack) and tries to call something which calls back into libpthread,
the thread_self() func fails to detect itself as the initial thread as
the current stack is now above the tos. The __pthread_find_self() func
kicks in, walks all the thread arrays, fails to find a hit, and then
walks into uninitialized memory for the thread descriptor. Use of this
garbage memory has obvious results -- things fall down & go boom.
To address this, I extend the current algorithm to automatically scale
back both the bottom and the top stack limits of the initial thread.
We use the current stack pointer at "thread boot time" only as a single
known point. The initial thread stack bottom is set to the bottom of
memory and the initial thread stack top is set to the top of memory.
Then as we create new stack threads, we figure out whether the new stack
is above or below the single known good address, and then scale back
either the tos or the bos accordingly.
Reviewed-by: Steven J. Magnani <steve@digidescorp.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
This patch will convert all the #ifdef USE_TLS and #if USE_TLS to
#if defined(USE_TLS) && USE_TLS.
By checking if the USE_TLS is defined before checking its value will result in
correct behavior for architectures not defining this config symbol.
Signed-off-by: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
Acked-by: Carmelo AMOROSO <carmelo.amoroso@st.com>
|
|
Once again all of these reduce the noise from gcc-4.4.
Replaces a few more (USE_TLS && HAVE___THREAD) with USE___THREAD while we need
to mess with them for this anyhow.
Signed-off-by: Ron Lee <ron@debian.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
Now they are only enabled if linuxthreads.old are selected.
|
|
|
|
__libc_accept __libc_close __libc_connect __libc_creat __libc_creat64
__libc_fsync __libc_lseek __libc_lseek64 __libc_msync __libc_nanosleep
__libc_open __libc_open64 __libc_pause __libc_read __libc_readv
__libc_recv __libc_recvfrom __libc_recvmsg
__libc_send __libc_sendmsg __libc_sendto
__libc_tcdrain __libc_wait __libc_waitpid __libc_write __libc_writev
They were removed from glibc 1 May 2004:
http://sources.redhat.com/ml/libc-hacker/2004-05/msg00001.html
|
|
*: remove checks of sigaction and sigprocmask results
in cases where they clearly can't fail:
sigaction(known_good_sig)
sigprocmask(known_good_how)
text data bss dec hex filename
- 393 4 0 397 18d libc/pwd_grp/lckpwdf.o
+ 382 4 0 386 182 libc/pwd_grp/lckpwdf.o
- 56 0 0 56 38 libc/signal/sigblock.o
+ 44 0 0 44 2c libc/signal/sigblock.o
- 211 0 0 211 d3 libc/signal/sigset.o
+ 202 0 0 202 ca libc/signal/sigset.o
- 56 0 0 56 38 libc/signal/sigsetmask.o
+ 44 0 0 44 2c libc/signal/sigsetmask.o
- 309 0 0 309 135 libc/unistd/sleep.o
+ 256 0 0 256 100 libc/unistd/sleep.o
|
|
|
|
text data bss dec hex filename
- 1179 13 2 1194 4aa libc/misc/syslog/syslog.o
+ 1165 13 2 1180 49c libc/misc/syslog/syslog.o
- 435 4 0 439 1b7 libc/pwd_grp/lckpwdf.o
+ 393 4 0 397 18d libc/pwd_grp/lckpwdf.o
- 38 0 0 38 26 libc/signal/sigandset.o
+ 32 0 0 32 20 libc/signal/sigandset.o
- 63 0 0 63 3f libc/signal/sigblock.o
+ 56 0 0 56 38 libc/signal/sigblock.o
- 22 0 0 22 16 libc/signal/sigempty.o
+ 20 0 0 20 14 libc/signal/sigempty.o
- 25 0 0 25 19 libc/signal/sigfillset.o
+ 20 0 0 20 14 libc/signal/sigfillset.o
- 34 0 0 34 22 libc/signal/sigisempty.o
+ 16 0 0 16 10 libc/signal/sigisempty.o
- 38 0 0 38 26 libc/signal/sigorset.o
+ 32 0 0 32 20 libc/signal/sigorset.o
- 119 0 0 119 77 libc/signal/sigpause.o
+ 113 0 0 113 71 libc/signal/sigpause.o
- 215 0 0 215 d7 libc/signal/sigset.o
+ 211 0 0 211 d3 libc/signal/sigset.o
- 63 0 0 63 3f libc/signal/sigsetmask.o
+ 56 0 0 56 38 libc/signal/sigsetmask.o
- 194 0 1 195 c3 libc/stdlib/abort.o
+ 183 0 1 184 b8 libc/stdlib/abort.o
- 323 0 0 323 143 libc/unistd/sleep.o
+ 309 0 0 309 135 libc/unistd/sleep.o
|
|
gcc?
text data bss dec hex filename
- 38015 18096 8636 64747 fceb lib/libpthread-0.9.30-svn.so
+ 38001 18096 8636 64733 fcdd lib/libpthread-0.9.30-svn.so
- 274842 1835 19012 295689 48309 lib/libuClibc-0.9.30-svn.so
+ 274779 1835 19012 295626 482ca lib/libuClibc-0.9.30-svn.so
|
|
Closes issue #5194
|
|
|
|
|
|
rather than the public weak ones so that the libc->libpthread forwarding code is able to work properly
this should fix the case where libpthread.so is not linked directly, but rather via another library:
app -> links to libfoo.so -> links to libpthread.so
and any function (like readdir_r) that does:
__UCLIBC_MUTEX_LOCK()
__UCLIBC_MUTEX_UNLOCK()
|
|
that all entries in the __pthread_functions point to functions within
libpthread, not identically-named functions in libc.
|
|
This should fix it.
|
|
2001-04-10 Ulrich Drepper <drepper@redhat.com>
* join.c (pthread_exit): Move code to new function __pthread_do_exit
which takes an extra parameter with the current frame pointer.
Call new function with CURRENT_STACK_FRAME.
(__pthread_do_exit): New function. Call __pthread_perform_cleanup
with the new parameter.
(pthread_join): Call __pthread_do_exit instead of pthread_exit.
* cancel.c (__pthread_perform_cleanup): Takes extra parameter. Use
this parameter as the initial value the cleanup handler records are
compared against. No active cleanup handler record must have an
address lower than the previous one and the initial record must be
above (below on PA) the frame address passed in.
(pthread_setcancelstate): Call __pthread_do_exit instead of
pthread_exit.
(pthread_setcanceltype): Likewise.
(pthread_testcancel): Likewise.
(_pthread_cleanup_pop_restore): Likewise.
* condvar.c (pthread_cond_wait): Likewise.
(pthread_cond_timedwait_relative): Likewise.
* manager.c (pthread_start_thread): Likewise.
* oldsemaphore.c (__old_sem_wait): Likewise.
* pthread.c (pthread_handle_sigcancel): Likewise.
* semaphore.c (__new_sem_wait): Likewise.
(sem_timedwait): Likewise.
* ptlongjmp.c (pthread_cleanup_upto): Also use current stack frame
to limit the cleanup handlers which get run.
* internals.h: Add prototype for __pthread_do_exit. Adjust prototype
for __pthread_perform_cleanup.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
is a useless attempt
|
|
|
|
|
|
|
|
of latest glibc version
|
