Re: libc6:m68k 2.28-1
On Sat, 8 Dec 2018, Michael Schmitz wrote:
>
> Can you strace the whole procedure (i.e. starting with the call to
> chroot) from the outside? With time stamps, for preference?
>
I'd rather wait for the results of Adrian's git bisection before spending
more time on this bug.
> The strace you did show with dash does indicate that SIGCHLD was sent by
> the child process / thread but even before that, the parent process got
> -ECHILD.
>
> To me, this would indicate that wait4 uses the wrong task struct to
> search for childs / threads to check.
>
> Might this have something to do with it?
>
> > /*
> > * Why not generic sys_clone, you ask? m68k passes all arguments on stack.
> > * And we need all registers saved, which means a bunch of stuff pushed
> > * on top of pt_regs, which means that sys_clone() arguments would be
> > * buried. We could, of course, copy them, but it's too costly for no
> > * good reason - generic clone() would have to copy them *again* for
> > * do_fork() anyway. So in this case it's actually better to pass pt_regs *
> > * and extract arguments for do_fork() from there. Eventually we might
> > * go for calling do_fork() directly from the wrapper, but only after we
> > * are finished with do_fork() prototype conversion.
> > */
> > asmlinkage int m68k_clone(struct pt_regs *regs)
> > {
> > /* regs will be equal to current_pt_regs() */
> > return do_fork(regs->d1, regs->d2, 0,
> > (int __user *)regs->d3, (int __user *)regs->d4);
> > }
> >
>
> Other architectures seem to treat clone() different from fork()?
>
These are probably questions for Andreas. glibc internals are not my
forte.
--
> Cheers,
>
> Michael
>
>
Reply to: