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] |