Date: Thu, 14 Jun 2018 16:11:52 +0300 From: Yanko Yankulov <yanko.yankulov@gmail.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-emulation@freebsd.org Subject: Re: two proposed linuxulator fixes + ptrace Message-ID: <CABTd0_pdF9RGmJHYDoL5f2ctewfWU_e0DsF=hkuqTVtFW2uhtA@mail.gmail.com> In-Reply-To: <20180614123659.GZ2493@kib.kiev.ua> References: <CABTd0_pqdAtHMH9gSJdebstASuoomYw1XLbkbbsMCUvtE-=vDA@mail.gmail.com> <20180614101324.GW2493@kib.kiev.ua> <CABTd0_p=5cqsN5TKtEWXY_oQXtGdJOyMHEzjoUJeaYcKShLCRQ@mail.gmail.com> <20180614123659.GZ2493@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > For the patch 1, TracePid, can you explain what is the meaning of the
> > > pid reported ?
> > >
> > > The TracerPid is the PID of the process currently ptrace-ing the
> process.
> > TracerPid 0 means no active tracer. So the patch is not semantically
> > correct as it always reports no tracer, but it got the program running.
> Ok, but what is the tracer ? Is it ptrace(2) debugger, or something
> else ?
>
Yes, any ptrace(2) debugger/truss/strace/whatever. The Linux code is:
tracer = ptrace_parent(p);
if (tracer)
tpid = task_pid_nr_ns(tracer, ns);
> >
> >
> > > For the patch 3, %r10 preservation for linux_rt_sigreturn, shouldn't
> the
> > > same handling applied to non-rt signal return ? And in fact, shouldn't
> > > it be done based on the return code instead of the syscall number ?
> Look
> > > at the amd64/amd64/vm_machdep.c:cpu_set_syscall_retval(), where I
> think
> > > EJUSTRETURN case is used by linux sigreturns.
> > >
> > The linux_rt_sigreturn seems to be the only signall return syscall.
> > The no rt_ version seems to be an old pre Linux 2.2 interface.
> >
> > The return code observation sounds right. Thanks. New patch. Ran a
> > quick check, the issue is still solved.
> Committed as r335135, thanks.
>
Great
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABTd0_pdF9RGmJHYDoL5f2ctewfWU_e0DsF=hkuqTVtFW2uhtA>