|
From: Julian S. <js...@ac...> - 2005-11-16 12:50:28
|
I've been looking into problems with LinuxThreads on a ppc system running 2.4.20 and glibc-2.3.2. A strange thing happens. Everything works fine until V tries to deliver a signal -- #32 or #33, one of the ones used internally by LinuxThreads -- to a thread whose SP (r1) points into the bss segment. That I found strange enough -- normally LinuxThreads allocates thread stacks via mmap of 8M chunks. However, I suspect perhaps the signalled thread was the manager thread and perhaps it has a small fixed size stack in bss. (Doesn't sound completely implausible). So all this works fine, the signal handler runs, but when the handler returns there's a problem: it returns to a 2-insn trampoline in the stack (created by stack_mcontext in sigframe-ppc32-linux.c). And that stack is in the bss and so is marked non-executable, and V notices that, and refuses to run that code, declaring a segfault instead. Then it all goes to hell. If I remove that no-translate-if-non-executable check, then it works fine. So I am mystified: - can anyone familiar with LinuxThreads internals comment on whether my inferences about the manager thread stack are correct? - should we be creating a bss segment which is executable as well as r/w-able? J |