[lkml]   [2003]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.5.64-mm6
    Eli Carter <> wrote:
    > Andrew Morton wrote:
    > >
    > [snip]
    > > kgdb.patch
    > I'm interested in this patch in your tree.

    You're brave.

    The kgdb patch is pretty nasty-looking code. I've managed to keep it working
    for every kernel since 2.4.0-test10 while avoiding actually looking at it.
    (I turn the monitor off when the patch needs fixing). Fed it through Lindent

    George Anzinger is maintaining another strain of the stub, and that mostly
    works OK and has improved features. But the diff is larger and I once had a
    couple of problems with it and need to spend more time testing it. It's up
    to date though.

    > (Just to warn you of my
    > biases, I'm currently working with the XScale/ARM arch.) I've noticed
    > some things about it in an initial look, namely:
    > There appears to be some code duplication between hex() and stubhex() in
    > arch/i386/kernel/gdbstub.c.

    No surprise there.

    > Also, the bulk of gdbstub.c appears to be generic code. There are a
    > number of functions that have x86 asm in them, but it looks to me on
    > initial viewing, that most of the logic is applicable to other arches.
    > Am I understanding that correctly?
    > Right now it looks like an arch would need to provide a way to:
    > - reboot the processor
    > - implement 'continue at address' and 'step one instruction from address'
    > - handle_exeption()
    > - printexception()
    > - correct_hw_break()
    > - regs_to_gdb_regs() and gdb_regs_to_regs()
    > Hmm, there's probably some more to that part...
    > The above is just for the gdbstub.c. I'm still reading the patch. :)
    > Would breaking the arch-independent parts out to linux/kernel/gdbstub.c
    > be a reasonable change or is that a dumb question? ;)

    That would be a fantastic thing to do. Note that there are already about ten
    kgdb stubs in the shipped kernel at present. If you can identify exactly
    which functions need to be provided by the architecture, pull that out into
    struct kgdb_operations, etc then it would make maintenance and addition of
    new support much easier.

    We might even end up with something we could submit for inclusion without
    first having to set up an account.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:33    [W:0.022 / U:6.960 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site