On 1/29/16, Jeffrey Merkey <jeffmer...@gmail.com> wrote: > 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 >
Sending version 3 with use of the BUG() macro. Then I don;t have to touch all these arches and it's totally non-intrusive. Jeff
