<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><span><br></span></div><div><span>please find my comments below.</span></div><div><br><span></span></div><div>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.</div><div><br></div><div>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.</div><div>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.<br></div><div>I
could be easily missing many things over here, as it is also just a thought from my side without detailed thinking.</div><div>of course on SMP; things become even more complex<br></div><div>and I even do not know the cost vs benefit ratio here.<br></div><div><br></div><div>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.</div><div><br></div><div><span>Oza: <br></span></div><div><span>kgdb doesnt seem to be inline anymore with kernel versions.</span></div><div><span>kdb, you need recompilation of kernel, and I am not sure it supports ARM and symbols<br>, it seems to be working with raw addresses.</span></div><div>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.</div><div>systemtap is again having tracing
capabilities.</div><div><br></div><div>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; <br></div><div>but I thought technically it might be feasible to in corporate breakpoint support in crash.<br></div><div><br></div><div>Regards,</div><div>Oza.<br><span></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> Wednesday, 8 August 2012 6:16 PM<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>> how about if crash utility supports breakpoints/watchpoints<br>> specifically hw level.<br>> of course need a kernel module to modify kernel memory as you<br>> suggested.<br>> <br>> was there any specific reason, you did not support this, thinking<br>> already kgdb and kdb types of utility available ?<br>> If we support breakpoint./watchpoints in crash, will the crash be<br>> able to offer much better than any other kernel debug tools ?<br>> <br>> what do you think?<br>> <br><br>I really don't understand how you expect the crash utility to <br>accomplish such a feat. 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>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>Dave<br><br><br><br> </div> </div> </div></body></html>