Re: [Crash-utility] using crash for ARM

Hi Dave, please find my comments below. Dave: If a breakpoint were set, it would generate an interrupt in the kernel, control would be passed to an interrupt handler, and any "work" would have to be done there (within the context of the interrupt handler) since the crash utility code could not run in user-space. Oza: yes, but not necessarily it has to be done in interrupt context, but signal could be sent to crash may be SIGTRAP or something. the whole kernel preemption could be disabled the moment the signal is delivered and whole kernel freezes and control always stay with crash utility. where you could inspect kernel datastructures at break-pointed kernel. I could be easily missing many things over here, as it is also just a thought from my side without detailed thinking. of course on SMP; things become even more complex and I even do not know the cost vs benefit ratio here. Dave: The crash utility has never done such a thing since its inception in early UNIX. And yes, kgdb, kdb, kprobes, ftrace, or systemtap would be more in line with what you're looking for. Oza: kgdb doesnt seem to be inline anymore with kernel versions. kdb, you need recompilation of kernel, and I am not sure it supports ARM and symbols, it seems to be working with raw addresses. ftrace is again tracing mechanism, I am not sure it supports breakpoints and watchpoint, of course you can debug the kernel but in a different way.  systemtap is again having tracing capabilities.

I could be easily wrong in thinking that crash could suport breakpoints and watchpoints, and I could be easily underestimating the capabilities of the tools you have mentioned; but I thought technically it might be feasible to incorporate breakpoint support in crash.