Re: GDB single-step fails on alpha (Re: CVS commit: src/share/mk)

[Rin Okuyama <rokuyama%rk.phys.keio.ac.jp@localhost>]

On 2016/12/08 12:40, Kamil Rytarowski wrote:
> On 08.12.2016 02:56, Rin Okuyama wrote:
> > Thank you very much for your kind explanation.
> >
> > On 2016/12/07 13:26, Kamil Rytarowski wrote:
> > > On 07.12.2016 04:27, Rin Okuyama wrote:
> > > > However, before proceeding further, we need to discuss undocumented
> > > > details related to PT_STEP; What should we do when a process steps into
> > > > a RAS? How about the case where PT_STEP is used against a process which
> > > > is already in single stepping? And so on...
> > >
> > > According to my understanding RAS is intended to be atomic sequence of
> > > operations and tracer mustn't interrupt or preempt it.
> >
> > process_sstep(9) should fail and return EFAULT in such a case?
> >
> > > There might exist only single tracer attached to a process.
> > >
> > > I don't think PT_STEP called twice for the same process makes sense in
> > > real life, it might be undefined behavior on port-specific basis and/or
> > > return error (in other words just prevent panic(9) and vulnerabilities).
> > > If I remember correctly process sets MD-style PSL_T variable to indicate
> > > trap after at least single instruction - if so, we cannot set this bit
> > > twice.
> >
> > Yes, it makes no sense. In my patch for powerpc/ibm4xx, process_sstep(9)
> > just returns 0 in that case. But I come to feel EFAULT more preferable.
> >
> > rin
>
> PT_STEP is restricted to stopped processes and return EBUSY. I've not
> been checking whether there is time window to sidestep it, if so I would
> rather try to eliminate it rather than handle it in MD-specific code.
>
>     467 		/*
>     468 		 *	(4) it's not currently stopped.
>     469 		 */
>     470 		if (t->p_stat != SSTOP || !t->p_waited /* XXXSMP */) {
>     471 			DPRINTF(("stat %d flag %d\n", t->p_stat,
>     472 			    !t->p_waited));
>     473 			error = EBUSY;
>     474 			break;
>     475 		}
>
>  -- src/sys/kern/sys_ptrace_common.c

I understand. Anyhow, MD codes must protect theirself from illegal
callers in some way. If MI codes are designed to have no sidestep,
KASSERT's are probably enough for this purpose.

I will update my patch of software single stepping for ppc/ibm4xx
before long. I'd appreciate it if you could give some advice!

Thanks,
Rin