This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [lkcd-general] dump format


On Tue, 2002-11-05 at 18:39, Rajeev Bector wrote:
> Hi LKCDers,
>         I have a question.. the current kernel dump seems to require a
> special crash tools. It'd be cool if we can use gdb to analyze the dump 
> once we have it.

Sort of; You can use Dave Anderson's crash program. I updated it for the
ia64 changes I made, and checked into the LKCD CVS repository, and Dave
Anderson's maintaining it at:

	        ftp://people.redhat.com/anderson

> I'd like to know if such support already exists. I believe it should just be
> a matter of dumping in the ELF format as opposed to the current format.

I suggest dumping in ELF format to Tom Morano about a year ago when I
started the ia64 work, but at the time he wasn't interested in the idea.
Jesse Barnes and I thought it seemed like the right way to go. I believe
this is how Solaris, FreeBSD, and NetBSD implement dumps.

I discussed it with Amit S. Kale, Hugh Dickins, Tigran Aivazian and Matt
D. Robinson and the plan, at least for a while, was for Amit to create
ELF files from the LKCD crash files. I think it was put on the back
burner, and integration into 2.5 was given priority. 

There are some advantages in not being restricted to dumping in ELF
format, for example we were able to dump the more important pages first.
I'm not sure if you can do that in ELF format, but I suspect you might
be able to arrange it.

I think using the exiting LKCD dump format and Dave's crash program are
a reasonable 1st start. It works great and Dave's interface to gdb is
helpful for walking through kernel data structures. lcrash has similar
walkers, but if you like src debuggers like GDB you will likely feel
more comfortable with crash.

The advantage to dumping in ELF format is the you could use ddd with gdb
on core files and use gdb macros to wall through kernel data structures.
In the past this has been a bit slow, for example when I was at 
Auspex and used the 'ps' macro it use to take about a second per 
entry in the SunOS proc table. The problem was just a bottle neck in the
symbol table lookup code and if speed were still a problem I think a
simple caching interface would fix the problem (if it hasn't been added
already).

It would be really nice to have formal parameters available to GDB
macros.Running the GDB simulator on the core files would be really
nice, then you could simulate the execution of the code that
caused OOPS/panic to be called.

-piet

> 
> thanks for your responses.
> 
> -- Rajeev
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm 
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Lkcd-general mailing list
> Lkcd-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lkcd-general
-- 
piet@www.piet.net


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]