On 13/10/2010 23:43, Richard Braun wrote:
On Wed, Oct 13, 2010 at 10:45:18PM +0100, Ed W wrote:
I traced the workaround to either disabling PAX_MPROTECT in the host
kernel, or calling "paxctl -m" on the test binary (was expecting to need
it on the library instead?)
Can anyone shed some light on why creating a pthread (old linux threads)
on 0.9.30.1 / 0.9.31 should be tickling mprotect?
Are you perfectly sure you're using the *old* LinuxThreads ? A quick
look only revealed calls to mprotect() in the "new" implementation.
Yes to using old linux threads
However, after further digging this is starting to look like an
interaction between newer pax and uclibc, eg perhaps pax 2.2 vs 2.1 is
the cause (not yet debugged that far)
It's taken me a little time to figure this out, but my build machine is
2.6.32 with pax 2.2 - I'm reasonably sure this used to work previously
with an earlier pax patch. The kernel which was working on the final
device was a 2.6.33 + pax 2.1, I just updated it to 2.6.35 + pax 2.2 and
now I see exactly the same failure to create threads there
Is it possible that someone smarter than me can please help me make
uclibc 0.9.31 work with pax 2.2 patches? At least some pointers on how
to debug and find the lines of code which are triggering the failure
would be helpful?
I have a temporary workaround to start fiddling with kernel patch sets
on the final device, but I'm starting to get painted into a corner on
the build machine...
Thanks
Ed W
(Alternatively, how close are we to seeing 0.9.32 and nptl get out of
the door? Seems like it's within spitting distance?)
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
