On Fri, 22 Jul 2011 10:06:00 +0200 Tejun Heo <tj@xxxxxxxxxx> wrote: > On Thu, Jul 21, 2011 at 04:44:47PM +0200, Oleg Nesterov wrote: > > On 07/21, Tejun Heo wrote: > > > Also, I think we really should standardize what gets reported in these > > > debug traps instead of letting each arch do its own thing. > > > > May be we can standardize .si_info within the single arch at least ;) > > > > I never understood what TRAP_HWBKPT/TRAP_BRKPT actually means, and > > I can be easily wrong. But, afaics, on x86 PTRACE_SINGLESTEP results > > in TRAP_TRACE. Unless the tracee steps over syscall, in this case > > user_single_step_siginfo() sets TRAP_BRKPT. Hmm. > > > > And unless I misread 248bed4b0f3c s390 thinks we need TRAP_HWBKPT. > > Yeah, it looks like a proper mess. It seems ptrace left too much for > archs to decide. Events to be reported should be defined by generic > ptrace code (there can be some exceptions but only few) and archs > should provide the mechanisms to implement them. I'm planning on > going through ptrace arch specifics soonish. Hopefully it can be > cleaned up somehow. The ptrace code differs because the architectures are different in regard to tracing, no? For s390 instruction single stepping and hardware breakpoints are the same thing. It all gets mapped to the progam-event-recording (PER) tracer. You have a start and an end address and a few events you want to see for this area (e.g. instruction fetch or storage alteration). I could special case ptrace with PTRACE_SINGLESTEP to return with TRAP_TRACE instead of TRAP_HWBKPT but that would be artificial. >From the hardware perspective its the same. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
