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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
