This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Thu, Jan 30, 2003 at 05:29:52PM +0100, Martin Schwidefsky wrote: > > > BTW: It seems to work just fine if stack_addr passed to clone > > is at least 8*16 bytes below end of particular mmaped area > > (this is on s390x). My wild guess is that the register save > > area is needed, which means clone.S should subtract 8*16 > > resp. 8*8 (on s390-32) bytes from stack_pointer before doing > > the syscall. > > Grr, it's the new clone implementation that stores %r6 on the > stack. It reloads it after the svc because the father has to > return with an unmodified %r6. But the restore of %r6 may not > be done in the child! Four letter words again. Try to move > the "lg %r6,48(%r15)" in clone.S after the two branches just > before the "br %r14". That should do the trick. Two more questions: lg %r5,168(%r15) /* load child_tid from stack */ l %r6,160(%r15) /* load tls from stack */ svc SYS_ify(clone) lg %r6,48(%r15) /* restore %r6 */ ltgr %r2,%r2 /* check return code */ jgm SYSCALL_ERROR_LABEL jz thread_start br %r14 1) Doesn't l (instead of lg) load just 32 bits from the stack (tls is void *)? 2) If the syscall fails, it should restore %r6 too, shouldn't it? Then it needs to be: svc SYS_ify(clone) ltgr %r2,%r2 /* check return code */ jz thread_start lg %r6,48(%r15) /* restore %r6 */ jgm SYSCALL_ERROR_LABEL br %r14 Jakub
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |