lkml.org 
[lkml]   [2008]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [git pull] kgdb-light -v10
    On Tue, Feb 12, 2008 at 01:38:39PM +0100, Ingo Molnar wrote:
    > So unless i forgot about something (please yell if so), it seems to me
    > kgdb is now pretty ready for an upstream merge.

    I don't know -- I have not reread everything. Please don't consider
    my comments as approval of the code base. I still think it does quite
    a lot of dubious and ugly things overall and should get far more clean up
    and get more testing too.

    > do spinning for now: we dont _ever_ want to break a correctly working
    > system with kgdb.

    Stopping all CPUs for indefinite time very much seems like
    "breaking a correctly working system" to me. In a correctly working system
    kgdb is never entered.

    > A valid counter-argument is _not_ to argue "but it would be nice to have
    > if the system is broken in X, Y and Z ways" (like you did), but to point
    > it out why the behavior we chose is wrong on a correctly working system.
    >
    > Yes, a buggy system might misbehave in various ways but my primary
    > interest is in keeping correctly working systems correct.

    The only way I know of to do that is gdb vmlinux /proc/kcore
    kgdb certainly isn't it.

    > And note that kgdb is not just a "debugger", it's a system inspection
    > tool. An intelligent, human-controlled printk.

    For that gdb vmlinux /proc/kcore already works fine. Or fireproxy.
    If that was the only goal we wouldn't need all that stub code.


    > > > just introduce unnecessary complexity.
    > >
    > > The question is less about actually having it as a module, but just if
    > > the interfaces are clean enough to allow it as a module. If not you
    > > should probably clean them up.
    >
    > but your contention is simply wrong. Most of our debugging
    > infrastructure is non-modular for a good reason. Modularization
    > increases complexity and that's exactly the wrong direction for

    The main complexity in module handling is handling (or rather preventing)
    module unload. I explicitely excluded that in my earlier mail.
    Module loading on the other hand tends to be relatively easy.

    I did a modular kernel debugger on my own some time ago and once
    the interfaces were clean it was very simple. I think the reverse
    is true too -- if having it as a module is easy then the interfaces
    are clean too. That is why I asked for it. It's a good basic
    sanity check on the design.

    >
    > > > no, not all architectures have it. This is a weak alias that is
    > > > otherwise not linked into the kernel.
    > >
    > > Can't be very many because oprofile needs it and it works on most
    > > archs now. Anyways, the right thing is to just add it to the
    > > architectures that still miss it, not reimplement it in kgdb.
    >
    > it's not reimplemented - kgdb_arch_pc() does not directly map to
    > instruction_pointer().

    If that is true then it is definitely misnamed and likely
    incorrectly implemented on the architecture in question.

    > > [...] If kgdb is active it should have priority over crash dumps.
    >
    > that's the approach we are taking: be as unintrusive as possible. This
    > means that the notifier here is registered at the lowest priority. You
    > might disagree with it but it's a completely sensible and consistent
    > approach.

    Yeah, it is consistently wrong agreed.

    -Andi



    \
     
     \ /
      Last update: 2008-02-12 14:17    [W:0.026 / U:0.104 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site