lkml.org 
[lkml]   [2006]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC] [Crash-utility] Patch to use gdb's bt in crash - works great with kgdb! - KGDB in Linus Kernel.
    From
    Date
    On Wed, 2006-08-30 at 16:40 -0400, Vivek Goyal wrote:
    > On Wed, Aug 30, 2006 at 12:35:21PM -0700, Piet Delaney wrote:
    > > >
    > > > Simple question -- and to be quite honest with you -- I don't
    > > > understand why you wouldn't want to simply use gdb alone
    > > > in this case?
    > >
    > > I don't see any reason for core file not to be read correctly by
    > > gdb. It's convenient to use gdb directly sometimes, for example
    > > while using the ddd GUI.
    > >
    >
    > You can run gdb to open core files as of today but the debugging
    > capability will be limited. For ex. kernel core headers have the info
    > of linearly mapped region only and they don't contain the virt address
    > info of non-linearly mapped regions. So one can not debug the non-linearly
    > mapped regions like modules.

    Amit's modified gdb might help for that problem. I haven't used
    it but it allows gdb to load debug information about modules. You
    can also use a script Amit wrote to explicitly load module info
    into stock gdb; that also might work with kernel core files.

    >
    > > kgdb isn't having any problems with kernel threads back traces.
    > > The kernel objects are tweaked with dwarf code, but I see no
    > > problem with using the same paradigm with crash. Works great.
    > >
    >
    > Can you give some more details on what do you mean by kernel objects
    > are tweaked with dwarf code.

    Attached is the cfi_annotations.patch patch from the kgdb-2.6.16 patch
    which is part of the kgdb patch series. I believe George Anzinger used
    a similar dwarf patch in the 2.6 mm series patches that Andrew provided.
    I think Tom Rini wrote both of them.


    >
    > > I'd prefer to have crash and ddd+gdb operate on kernel core files.
    > >
    >
    > You can already do that. Its just a matter of figuring out how to
    > get good backtraces both with "crash" as well as "gdb".

    I think Tom Rini's cfi_annotations could be a big part of that solution.

    >
    > > Even better it would be nice to be able to simulate execution on
    > > a stack of a core file to be able to re-execute code that caused
    > > the crash. I frequently found it convenient after a panic to move
    > > the pc to the end of panic, and continue back up the stack to a
    > > break point at the system call. Then I'd use the GUI to move the
    > > pc to before the execution of the system call and execute it again
    > > and watch how the return value was derived that caused the panic.
    > >
    > > I expect that if you run a kgdb kernel, including the drarf code,
    > > that gdb will have no problem with core dumps. It's convenient to
    > > have kgdb configured in the kernel and have the option to continue
    > > analysis later with gdb/crash.
    > >
    >
    > Is kgdb mainline? I think some time back Andrew had dropped the patches
    > from -mm too.

    Yes, I think he had a number of issues with the kgdb patch but I can't
    recall reading exactly what they are. One I believe is that the kgdb
    patch should be completly non-invasive if not configured in. Currently
    some files that are patched don't have #ifdef CONFIG_KGDB in them. I
    noticed one last night while checking in some code.

    I'd like to put those #ifdef's back in and make it part of the std
    distribution. As I recall George Anzinger's patch had absolutely no
    impact on the kernel if not configured in. Seems very important to me.


    > I don't know if distros carry kgdb or not? So not sure
    > for how many people will it be helpful to enable kgdb and then take
    > core dumps for better back traces.

    More for larger servers like a Sun NUMA system. I'd find it convenient
    to be able to go back a look at a crash of something that I looked at
    previously. Might be good for bug reports to have references to core
    files backing up a bug fix.

    >
    > I don't know much about tweaking objects with dwarf code but got a
    > general question. Why can't it be an independent patch in kernel
    > independent of kgdb. (If it helps in getting better backtraces.)

    Exactly. Locally I just checked in code that I expect will be useful for
    kgdb or kdump. Stuff like compiling the kernel -O0 and converting
    static inline functions to inline. Code to provide dwarf info and
    save registers during a panic seem to also qualify.

    My preference is for kgdb, like kexec, to become part of the
    mainstream kernel as a configurable component. Perhaps Andrew
    could enumerate his issues. It would make cooperation between
    kgdb and crash a bit easier and make kernel debugging a lot
    easier for the masses. Recent kgdb patches seem to be getting
    much better.

    -piet

    >
    > Thanks
    > Vivek
    >
    --
    Piet Delaney
    BlueLane Teck
    W: (408) 200-5256; piet@bluelane.com
    H: (408) 243-8872; piet@piet.net


    -
    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: 2006-08-30 23:45    [W:4.834 / U:0.100 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site