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 <[email protected]>
To: paawan oza <[email protected]>
Cc: "Discussion list for crash utility usage, maintenance and development"
<[email protected]>
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
--
Crash-utility mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/crash-utility
