[Crash-utility] using crash for ARM

paawan oza paawan1982 at yahoo.com
Wed Aug 8 18:29:42 UTC 2012


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 at redhat.com>
To: paawan oza <paawan1982 at yahoo.com> 
Cc: "Discussion list for crash utility usage, maintenance and development" <crash-utility at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20120808/a9ab6ef3/attachment.htm>


More information about the Crash-utility mailing list