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

[Jeffrey Merkey]

On 1/29/16, Ingo Molnar <mingo@xxxxxxxxxx> wrote:
>
> * 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
>

You were not included on the post since you are not a maintainer of
watchdog.c so I am confused as to why you are nacking and trolling me
on something not in your area.

Jeff