musl/src/thread/arm, branch v1.0.2 musl - an implementation of the standard library for Linux-based systems clone: make clone a wrapper around __clone 2014-02-10T02:07:43+00:00 Bobby Bingham koorogi@koorogi.info 2014-02-07T04:11:22+00:00 fdf5f1b13123883ac1d5e298e5f32c7ed43578ce The architecture-specific assembly versions of clone did not set errno on failure, which is inconsistent with glibc. __clone still returns the error via its return value, and clone is now a wrapper that sets errno as needed. The public clone has also been moved to src/linux, as it's not directly related to the pthreads API. __clone is called by pthread_create, which does not report errors via errno. Though not strictly necessary, it's nice to avoid clobbering errno here. 
The architecture-specific assembly versions of clone did not set errno on
failure, which is inconsistent with glibc.  __clone still returns the error
via its return value, and clone is now a wrapper that sets errno as needed.
The public clone has also been moved to src/linux, as it's not directly
related to the pthreads API.

__clone is called by pthread_create, which does not report errors via
errno.  Though not strictly necessary, it's nice to avoid clobbering errno
here.
add support for TLS variant I, presently needed for arm and mips 2012-10-15T22:51:53+00:00 Rich Felker dalias@aerifal.cx 2012-10-15T22:51:53+00:00 9ec4283b28cf676292fd5c6f681bef1e90e30c18 despite documentation that makes it sound a lot different, the only ABI-constraint difference between TLS variants II and I seems to be that variant II stores the initial TLS segment immediately below the thread pointer (i.e. the thread pointer points to the end of it) and variant I stores the initial TLS segment above the thread pointer, requiring the thread descriptor to be stored below. the actual value stored in the thread pointer register also tends to have per-arch random offsets applied to it for silly micro-optimization purposes. with these changes applied, TLS should be basically working on all supported archs except microblaze. I'm still working on getting the necessary information and a working toolchain that can build TLS binaries for microblaze, but in theory, static-linked programs with TLS and dynamic-linked programs where only the main executable uses TLS should already work on microblaze. alignment constraints have not yet been heavily tested, so it's possible that this code does not always align TLS segments correctly on archs that need TLS variant I. 
despite documentation that makes it sound a lot different, the only
ABI-constraint difference between TLS variants II and I seems to be
that variant II stores the initial TLS segment immediately below the
thread pointer (i.e. the thread pointer points to the end of it) and
variant I stores the initial TLS segment above the thread pointer,
requiring the thread descriptor to be stored below. the actual value
stored in the thread pointer register also tends to have per-arch
random offsets applied to it for silly micro-optimization purposes.

with these changes applied, TLS should be basically working on all
supported archs except microblaze. I'm still working on getting the
necessary information and a working toolchain that can build TLS
binaries for microblaze, but in theory, static-linked programs with
TLS and dynamic-linked programs where only the main executable uses
TLS should already work on microblaze.

alignment constraints have not yet been heavily tested, so it's
possible that this code does not always align TLS segments correctly
on archs that need TLS variant I.
fix arm clone syscall bug (no effect unless app uses clone) 2012-09-27T22:56:10+00:00 Rich Felker dalias@aerifal.cx 2012-09-27T22:56:10+00:00 e0ea44cb764fcdbe8515f22096930bede2c7896f the code to exit the new thread/process after the start function returns was mixed up in its syscall convention. 
the code to exit the new thread/process after the start function
returns was mixed up in its syscall convention.
avoid blx instruction which does not exist on armv4t or armv4 2012-07-15T00:15:02+00:00 Rich Felker dalias@aerifal.cx 2012-07-15T00:15:02+00:00 7be3b5a073e77f1147acfa728725f9f81d20ceb0 






fix bad opcode in arm syscall_cp_asm
2012-05-23T19:58:53+00:00

Rich Felker
dalias@aerifal.cx

2012-05-23T19:58:53+00:00

4d4f13e5813f3b1f7e7fd43cfe1a5da641dca96c












fix issue with longjmp out of signal handlers and cancellation
2012-05-23T19:45:41+00:00

Rich Felker
dalias@aerifal.cx

2012-05-23T19:45:41+00:00

4da268f74b90696563db4f5d9d2b8e1c1351bdc6

stale state information indicating that a thread was possibly blocked
at a cancellation point could get left behind if longjmp was used to
exit a signal handler that interrupted a cancellation point.

to fix the issue, we throw away the state information entirely and
simply compare the saved instruction pointer to a range of code
addresses in the __syscall_cp_asm function. all the ugly PIC work
(which becomes minimal anyway with this approach) is defered to
cancellation time instead of happening at every syscall, which should
improve performance too.

this commit also fixes cancellation on arm, which was mildly broken
(race condition, not checking cancellation flag once inside the
cancellation point zone). apparently i forgot to implement that. the
new arm code is untested, but appears correct; i'll test and fix it
later if there are problems.





stale state information indicating that a thread was possibly blocked
at a cancellation point could get left behind if longjmp was used to
exit a signal handler that interrupted a cancellation point.

to fix the issue, we throw away the state information entirely and
simply compare the saved instruction pointer to a range of code
addresses in the __syscall_cp_asm function. all the ugly PIC work
(which becomes minimal anyway with this approach) is defered to
cancellation time instead of happening at every syscall, which should
improve performance too.

this commit also fixes cancellation on arm, which was mildly broken
(race condition, not checking cancellation flag once inside the
cancellation point zone). apparently i forgot to implement that. the
new arm code is untested, but appears correct; i'll test and fix it
later if there are problems.







fix typo in arm clone() asm
2011-10-09T04:02:39+00:00

Rich Felker
dalias@aerifal.cx

2011-10-09T04:02:39+00:00

2b89e56c94c1ce4369a3c7a17304df17df1fa822












initial commit of the arm port
2011-09-18T20:44:54+00:00

Rich Felker
dalias@aerifal.cx

2011-09-18T20:44:54+00:00

d960d4f2cbf18ff3476c7ac03698ec253885dd8e

this port assumes eabi calling conventions, eabi linux syscall
convention, and presence of the kernel helpers at 0xffff0f?0 needed
for threads support. otherwise it makes very few assumptions, and the
code should work even on armv4 without thumb support, as well as on
systems with thumb interworking. the bits headers declare this a
little endian system, but as far as i can tell the code should work
equally well on big endian.

some small details are probably broken; so far, testing has been
limited to qemu/aboriginal linux.





this port assumes eabi calling conventions, eabi linux syscall
convention, and presence of the kernel helpers at 0xffff0f?0 needed
for threads support. otherwise it makes very few assumptions, and the
code should work even on armv4 without thumb support, as well as on
systems with thumb interworking. the bits headers declare this a
little endian system, but as far as i can tell the code should work
equally well on big endian.

some small details are probably broken; so far, testing has been
limited to qemu/aboriginal linux.