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 in corporate breakpoint support in
crash.
Regards,
Oza.
________________________________
From: Dave Anderson <anderson(a)redhat.com>
To: paawan oza <paawan1982(a)yahoo.com>
Cc: "Discussion list for crash utility usage, maintenance and development"
<crash-utility(a)redhat.com>
Sent: Wednesday, 8 August 2012 6:16 PM
Subject: Re: [Crash-utility] using crash for ARM
----- Original Message -----
how about if crash utility supports breakpoints/watchpoints
specifically hw level.
of course need a kernel module to modify kernel memory as you
suggested.
was there any specific reason, you did not support this, thinking
already kgdb and kdb types of utility available ?
If we support breakpoint./watchpoints in crash, will the crash be
able to offer much better than any other kernel debug tools ?
what do you think?
I really don't understand how you expect the crash utility to
accomplish such a feat. 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.
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.
Dave