Re: [RFC] [Crash-utility] Patch to use gdb's bt in crash - worksgreat with kgdb! - KGDB in Linus Kernel.

[Piet Delaney]

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@xxxxxxxxxxxx
H: (408) 243-8872; piet@xxxxxxxx


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