<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span>Hi Dave,</span></div><div><br><span></span></div><div><span>I am sorry, If I over-enthusiastically thought crash could support kernel breakpoints while originally it was not meant to do that.</span></div><div><span>I think I better look at other utilities and evaluate their capability.</span></div><div><span>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.</span></div><div><br><span></span></div><div><span>Regards,</span></div><div><span>Oza.</span></div><div><br></div> <div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"> <div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"> <div dir="ltr"> <font face="Arial" size="2"> <hr size="1"> <b><span style="font-weight:
bold;">From:</span></b> Dave Anderson <anderson@redhat.com><br> <b><span style="font-weight: bold;">To:</span></b> paawan oza <paawan1982@yahoo.com> <br><b><span style="font-weight: bold;">Cc:</span></b> "Discussion list for crash utility usage, maintenance and development" <crash-utility@redhat.com> <br> <b><span style="font-weight: bold;">Sent:</span></b> Thursday, 9 August 2012 12:08 AM<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [Crash-utility] using crash for ARM<br> </font> </div> <br><br><br>----- Original Message -----<br>> <br>> <br>> Hi Dave,<br>> <br>> <br>> please find my comments below.<br>> <br>> Dave: If a breakpoint were set, it would<br>> generate an interrupt in the kernel, control would be passed<br>> to an interrupt handler, and any "work" would have to be done<br>> there (within the context of the interrupt handler) since the<br>> crash utility code could not
run in user-space.<br>> <br>> Oza: yes, but not necessarily it has to be done in interrupt context,<br>> but signal could be sent to crash may be SIGTRAP or something.<br>> the whole kernel preemption could be disabled the moment the signal<br>> is delivered and whole kernel freezes and control always stay with<br>> crash utility. where you could inspect kernel datastructures at<br>> break-pointed kernel.<br>> <br>> I could be easily missing many things over here, as it is also just a<br>> thought from my side without detailed thinking.<br>> of course on SMP; things become even more complex<br>> <br>> and I even do not know the cost vs benefit ratio here.<br>> <br>> Dave: The crash utility has never done such a thing since its inception<br>> in early UNIX. And yes, kgdb, kdb, kprobes, ftrace, or systemtap<br>> would be more in line with what you're looking for.<br>> <br>> Oza:<br>> <br>>
kgdb doesnt seem to be inline anymore with kernel versions.<br>> kdb, you need recompilation of kernel, and I am not sure it supports <br>> ARM and symbols, it seems to be working with raw addresses.<br>> ftrace is again tracing mechanism, I am not sure it supports<br>> breakpoints and watchpoint, of course you can debug the kernel but<br>> in a different way. systemtap is again having tracing capabilities.<br><br>I'm not sure what you mean by that -- systemtap is far more<br>than a tracer. You can write very involved handlers to run<br>when the breakpoint is hit.<br> <br>> I could be easily wrong in thinking that crash could suport<br>> breakpoints and watchpoints, and I could be easily underestimating<br>> the capabilities of the tools you have mentioned;<br>> <br>> but I thought technically it might be feasible to incorporate<br>> breakpoint support in crash.<br> <br>You're on your own...<br><br>Dave<br>
<br><br><br> </div> </div> </div></body></html>