----- Original Message -----
>
>
> 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'm not sure what you mean by that -- systemtap is far more
than a tracer.  You can write very involved handlers to run
when the breakpoint is hit.

> 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.

You're on your own...

Dave