Re: [PATCH 01/31] Add hard/soft lockup debugger entry points

[Ingo Molnar]

* Jeffrey Merkey <jeffmerkey@xxxxxxxxx> wrote:

> On 1/28/16, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> > On Thu, 28 Jan 2016, Jeffrey Merkey wrote:
> >> On 1/28/16, Thomas Gleixner <tglx@xxxxxxxxxxxxx> 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 <mingo@xxxxxxxxxx>

> 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