Created attachment 374817 [details] test-case: clone(CLONE_VM) triggers SIGILL Description of problem: clone(CLONE_VM) triggers SIGILL Version-Release number of selected component (if applicable): glibc-2.11-2.x86_64 kernel 2.6.31.5-127.fc12.x86_64 How reproducible: always Steps to Reproduce: run the attached test-case Actual results: The subthread killed by SIGILL, si_code == 2 (ILL_ILLOPN), the faulting instruction is "vmovdqa" in /lib64/ld-2.11.so:_dl_x86_64_restore_sse() Expected results: clone() should succeed Additional info: Dump of assembler code for function _dl_x86_64_restore_sse: 0x0000003ad1e14950 <_dl_x86_64_restore_sse+0>: cmpl $0x0,0x20a5f9(%rip) # +0x3ad201ef50 0x0000003ad1e14957 <_dl_x86_64_restore_sse+7>: js 0x3ad1e149aa <_dl_x86_64_restore_sse+90> ---> 0x0000003ad1e14959 <_dl_x86_64_restore_sse+9>: vmovdqa %fs:0x80,%ymm0 0x0000003ad1e14963 <_dl_x86_64_restore_sse+19>: vmovdqa %fs:0xa0,%ymm1 0x0000003ad1e1496d <_dl_x86_64_restore_sse+29>: vmovdqa %fs:0xc0,%ymm2 0x0000003ad1e14977 <_dl_x86_64_restore_sse+39>: vmovdqa %fs:0xe0,%ymm3 0x0000003ad1e14981 <_dl_x86_64_restore_sse+49>: vmovdqa %fs:0x100,%ymm4 0x0000003ad1e1498b <_dl_x86_64_restore_sse+59>: vmovdqa %fs:0x120,%ymm5 0x0000003ad1e14995 <_dl_x86_64_restore_sse+69>: vmovdqa %fs:0x140,%ymm6 0x0000003ad1e1499f <_dl_x86_64_restore_sse+79>: vmovdqa %fs:0x160,%ymm7 0x0000003ad1e149a9 <_dl_x86_64_restore_sse+89>: retq 0x0000003ad1e149aa <_dl_x86_64_restore_sse+90>: movdqa %fs:0x80,%xmm0 Stack trace: #0 _dl_x86_64_restore_sse () at ../sysdeps/x86_64/dl-trampoline.S:222 222 vmovdqa %fs:RTLD_SAVESPACE_SSE+0*YMM_SIZE, %ymm0 #0 _dl_x86_64_restore_sse () at ../sysdeps/x86_64/dl-trampoline.S:222 #1 0x0000003ad1e0dbf5 in _dl_fixup (l=<value optimized out>, reloc_arg=<value optimized out>) at +../elf/dl-runtime.c:126 #2 0x0000003ad1e142e5 in _dl_runtime_resolve () at ../sysdeps/x86_64/dl-trampoline.S:41 #3 0x0000000000400855 in thread_func (unused=<value optimized out>) at CLONE.c:14 #4 0x0000003ad22ddf3d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
If you call clone directly you are responsible for setting up the TLS area yourself.
This is a synthetic test to duplicate a problem that was observed without the direct use of clone, I believe. I could be wrong.
(In reply to comment #2) > > This is a synthetic test to duplicate a problem that was observed without the > direct use of clone, I believe. I could be wrong. No, ptrace-tests use clone() directly, I think to avoid the dependency with libpthread. This used to work, now it turns out we have to rewrite these tests to use pthread_create(). If clone() requires setting the TLS area, then it can't be used in more or less "portable" manner, afaics.