On 1/29/16, Ingo Molnar <mi...@kernel.org> wrote: > > * Jeffrey Merkey <jeffmer...@gmail.com> wrote: > >> On 1/28/16, Thomas Gleixner <t...@linutronix.de> wrote: >> > On Thu, 28 Jan 2016, Jeffrey Merkey wrote: >> >> On 1/28/16, Thomas Gleixner <t...@linutronix.de> wrote: >> >> > I'm probably missing something obvious here. >> >> >> >> It's a pain in the butt to grep around through assembly language in a >> >> function in watchdog.c that has everything declared static with no >> >> symbols. >> >> It's a lot easier just to insert an INT3 in the section of code that >> >> has the >> >> mouse caught in the trap (inside a function that triggers the hard >> >> lockup) -- >> >> after all -- that's what the instruction is for. >> > >> > AFAICT, debuggers can set breakpoints on arbitrary code lines without >> > grepping >> > through assembly language. If you don't have the debug information >> > available, >> > then using a debugger is pointless anyway. >> > >> > This is beyond silly. If we follow your argumentation we need another >> > gazillion of conditional breakpoints in the kernel. Definitely not. >> > >> > Thanks, >> > >> > tglx >> >> If you don't get it Thomas, I don't know what else to say. [...] > > He provided specific technical arguments: > >> > AFAICT, debuggers can set breakpoints on arbitrary code lines without >> > grepping >> > through assembly language. > > Thomas's argument is that live kernel debuggers are already able to insert > breakpoints just fine, without us having to artificially uglify the source > code > like your patch series does. > > ... but instead of addressing his technical point (which is perfectly > valid), you > replied with a condescending tone. You are quickly establishing yourself as > a > contributor who is difficult to work with. > > As to Thomas's point: on typical distro kernels we at minimum have the > kallsyms > data, but also the System.map in general on packaged kernels. Having > function > symbols is more than enough to start a disassembly from, and the breakpoint > can be > set from there. > > If you intentionally and completely throw away all symbol data then > debuggability > decreases drastically. That's nothing new - don't do that. Note that > disassembly > from a live debugger is generally _still_ possible: as function entries are > > usually pretty easy to recognize signatures - and generally there's enough > padding > for cache alignment reasons for even a 'blind' disassembly starting say 1KB > before > the intended breakpoint to actually show correct disassembly. > > So I don't see any technical reason to apply your patch-set in that form. > >> [...] Right now the only debugger that provides disassembly on a single >> running >> live Linux system is the one I use unless you want to use a serial >> connection >> with kgdb. [...] > > Given that at least in the x86 space most systems have a real or an emulated > > serial line (the latter via management interfaces), this isn't a big > limitation in > practice. > >> [...] All you are convincing me of is that you don't use a debugger or sit >> >> around looking at dissassembly all day long on live linux systems looking >> for >> bugs or you would understand why this is so helpful. So I totally >> understand >> why you don't get this. > > Just for the record, I don't see the point of the many artificial and ugly > breakpoints either that your series adds, so I'm NAK-ing this intrusive > form, > until better justification is given: > > NAKed-by: Ingo Molnar <mi...@kernel.org> > >> Think of it like git. Before git was around, everything was done with >> manual >> patches. Now we have git, and everything can be automated. Same thing >> here. >> Why do I want to grep around looking for a bug when I can have linux find >> it for >> me. > > Non sequitur: uglifying kernel source code (which has a very real cost for > only > marginal benefit - making it a net negative) has very little to do with the > > utility of Git (which has small cost for a big benefit, which makes it a net > > positive). > > Thanks, > > Ingo >
It's not intrusive to use the BUG() macro to insert a breakpoint instead of the ud2a instruction to trigger a breakpoint. All of thomas technical arguments were addressed to the extent he communicated any other than political banter. Jeff
