lkml.org 
[lkml]   [2004]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: kgdb support in vanilla 2.6.2
    Andrew Morton wrote:
    > Tom Rini <trini@kernel.crashing.org> wrote:
    >
    >>Andrew, what features of George's version don't you like?
    >
    >
    > This is bad:
    >
    > akpm:/usr/src/25> grep '^+#ifdef' patches/kgdb-ga.patch | wc -l
    > 83
    >
    > and the fact that it touches 36 different files.

    Been away from this for a while, but I do think this needs a comment. The fact
    that it touches 36 files is tilted rather strongly in that a good number of
    those files are in the Document/* tree. I.e. there is a rather larger amount of
    documentation.

    As to the #ifdefs, I once worked on a kernel (HPUX if you must know) where you
    could NOT remove the debug stub and its bits. Turns out the kernel began to
    depend on the code that was supposed to be debugging it. I rather strongly try
    to avoid Heisenberg and the nasty thinks that arise from this sort of thing. I
    think you will find that most of those #ifdefs are "#ifdef CONFIG_KGDB" so that
    it you turn it off it is just as if the patch was not done (save the configure
    script, of course).

    There is also the attempt to make one patch cover several kernels (such as in
    the 2.4 case where we may have O(1) or not) and also the preempt or not AND at
    the same time, want to debug the preempt code.
    >
    > Any time I've had to do any maintenance work against that stub I get lost
    > in a twisty maze and just whine at George about it. It's just all over the
    > place. Yes, this is partly the nature of the beast, but I don't see that a
    > ton of effort has been put into reducing the straggliness.

    Yes, I agree. Some of this is caused by the need to work with a rather fixed
    interface to gdb. We would, for example, like to tell gdb to flush its cache
    from time to time. It would also be nice if gdb were to hint to us about what
    it was trying to do. The single step over a break point comes to mind here, as
    does the function call set up. Still, improvements can be made.
    >


    --
    George Anzinger george@mvista.com
    High-res-timers: http://sourceforge.net/projects/high-res-timers/
    Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:01    [W:0.025 / U:59.652 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site