sh port of musl possibly broken due to toolchain and kernel issues

sh port of musl possibly broken due to toolchain and kernel issues

[Rich Felker]

Due to the following issue which I reported to both GCC and binutils:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66609
https://sourceware.org/bugzilla/show_bug.cgi?id=18561

most builds of musl for sh probably have subtle breakage due to
incorrect binding of local weak definitions of symbols instead of
correctly resolving the strong definition. At least cancellable
syscalls were observed to be broken (non-cancellable), but other
functionality may be affected too. A workaround is to build with -m1
(sh1 codegen) since sh1 lacks the instructions that the buggy
relocation type would be used with, but this only works for nofpu
targets (sh2/3 or sh4-nofpu).

The kernel issue I reported ("SH sigcontext ABI is broken" thread)
with sigcontext also affects everything no-fpu (pre-sh4). Due to
mismatched layout of mcontext_t and ucontext_t depending on the
hardware (not tied to userspace ABI like it would need to be),
attempting to use pthread_cancel on nofpu kernels will potentially
corrupt the target thread's stack and will throw it into an infinite
loop.

I'm working on getting them all fixed.

Rich