[Crash-utility] using crash for ARM

[paawan oza]

Hi Dave,

I am sorry, If I over-enthusiastically thought crash could support kernel breakpoints while originally it was not meant to do that.
I think I better look at other utilities and evaluate their capability.
but I guess from your side, you do not seem to be keen on idea of breakpoints, specially when there are other plenty of utilities available.

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: Thursday, 9 August 2012 12:08 AM
Subject: Re: [Crash-utility] using crash for ARM
 


----- 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20120809/92aa5317/attachment.htm>