On 07.12.2016 04:27, Rin Okuyama wrote: > On 2016/12/06 22:29, Kamil Rytarowski wrote: >> I consider PT_STEP feature as desired with the goal to be independent >> from the GNU toolchain and without need to reimplement basic features in >> per-platform basis in a custom debugger. > > I agree. I feel that it is not so difficult to implement PT_STEP for > alpha based on software single stepping. We already have it for mips > (not currently enabled), and I wrote it for powerpc/ibm4xx (cf. > port-evbppc/24096). > Thank you for this work! > 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. 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. My only modification the PT_STEP interface would be to leave room for PT_SUSPEND in future, therefore for positive values of data resume LWP with identity "data" unless they were explicitly stopped with PT_SUSPEND. But on the other hand it might not have use in real-life this is why I'm holding on with implementation -- I want to implement it in a context of a real life debugger. >> I was trying to find users of FIX_SSTEP() in the NetBSD CVS history (git >> log -p|grep) and I couldn't find any users till BSD4.4-lite2 -- it's a >> dead macro since then, older code is partially removed and I couldn't >> find users back in 1994 year. The alpha port could be the first user! > > For mips and powerpc/ibm4xx, we do not need it; the trap handler takes > care of them. But there might be some reasons to do so. We should > carefully examine if we decide to implement it. > Originally, I wanted to take rid of it as there are no ports using it. For now I will leave it as it is, at least until all existing ports will ship with PT_STEP. > Thanks, > Rin
Attachment:
signature.asc
Description: OpenPGP digital signature