On 12/01, Roland McGrath wrote: > > > So. Any ptrace test which uses clone() is broken, at least on x86_64. > > If you use clone() directly then you need to have the code run in that > child be purely under your control. You can't use miscellaneous libc > calls nor any libpthread calls, only ones you are sure do not require > any thread setup.
Yes, sure, this is clear. > The only thing that changed about this recently in glibc is that even > more code paths through the dynamic linker now happen to depend on > thread setup. Yes, I see. > > Jan, Roland, how should we fix this? We can rewrite the code to use > > pthread_create(), this should be trivial. Unfortunately, libpthread > > is not trivial, it can shadow the problem and complicate the testing. > > We should avoid library code more thoroughly, not use more of it. > As well as being complex, it also varies a lot across systems and > interferes with using the same sources to translate to exact > kernel-level testing across various people's development environments. Agreed. > I think the best bet is to link with -Wl,-z,now I think this should help. > and then minimize the > library code you rely on. (It really only matters to be extra careful > about that for the code running in the clone child.) So you can use > syscall() if you are not relying on its error-case behavior--if the > system call fails, the function will set errno, which can rely on the > TLS setup. IIRC, all ptrace-tests's sub-threads created by clone are very simple, they only do very basic systemcalls like pause/exit. The test-case I sent does syscall(__NR_exit) and nothing more, but I guess BIND_NOW should help. > > And the stupid question. If I create the subthread via pthread_create(), > > how can I know its tid? I grepped glibc-2.11, and afaics pthread_create > > returns the pointer to "struct pthread" which has "pid_t tid" but I can > > not find the helper which returns ->tid and "struct pthread" is not > > exported. > > There is no official exported way. You can use syscall(__NR_gettid). Yes, but this way the caller of pthread_create() should communicate with the sub-thread to know its tid, this is not suitable for ptrace tests. Oleg.
