Re: [lkcd-devel] Re: Re: lcrash and debian

----- Original Message -----
From: "Corey Minyard" <[email protected]>
To: "Tom Morano" <[email protected]>
Cc: "Michael Holzheu" <[email protected]>; "Micah Anderson"
<[email protected]>; "Hariprasad Nellitheertha" <[email protected]>;
"lkcd-devel" <[email protected]>;
<[email protected]>;
<[email protected]>
Sent: Monday, October 04, 2004 10:23 AM
Subject: Re: [lkcd-devel] Re: [lkcd-general] Re: lcrash and debian


> Tom Morano wrote:
>
> >I guess I don't quite see where lcrash is so tied to the kernel version.
The
> >only thing that would cause it problems is a functional change in a
kernel
> >data structure (remove/change a key struct member, etc.). Of course that
may
> >not be the case with the version currently in the CVS tree (I've noticed
> >that there are some problems with the treatment of local copies of dump
> >headers, for example). Being able to do gdb operations is a nice feature,
> >however lcrash can nicely print arbitrary data structures too, so I'm not
> >quite sure what you mean by your last statement.\
> >
> >
> This is exactly what I'm talking about.  If a user turns on/off things
> like preemption and SMP, major kernel data structures change.  Plus,
> lcrash will only work with one version of the LKCD header (we currently
> support two).  I don't want to have to compile a different version of
> lcrash for each possibility.  And our users will complain bitterly if
> they have to do that.

This is not the sort of change I'm referring to. I'm talking about more
functional changes between kernel versions, like when the next and prev
pointers in the task_struct were changed to be list_head structs. This sort
of change requires a similar change to be made in the crash dump analysis
tool (crash or lcrash). If a particular kernel is built with certain ifdefs
turned on or off, that should be something the tools can handle. lcrash
should be able to handle this. The version we are using at SGI can. The
trick is to use the struct definition in the type information to determine
the proper member offset, size, etc. If the current lcrash does not handle
this sort of thing, I would consider that a bug that  needs to be fixed.

>
> On the second part, you mean I can type something like:
>
>   p *(ipmi_interfaces[0])
>
> and get a nicely formatted output, just like gdb?

lcrash does not require a full kernel (with debug info intact) to run. All
it needs is the Kerntypes file to get kernel data type definitions. I
understand that crash does need a full kernel to work properly (I might not
be right abuot this). Your above example assumes that the crash analysis
tool knows what data type impi_interfaces is. If you were to issue the same
command in lcrash, but instead of having the variable name, have a typecast
reference to the variable address (we do know that address to use for this
symbol -- from System.map), then it would print out a formatted struct (not
quite like gdb, but more like it is declared in a C header file). lcrash
should be able to do the same thing as crash if it has a full kernel to work
with. I don't think that it currently can do this. Nor is it able to get
line number information for task backtraces. Again, a full kernel would be
required for this. I think a bit of work is required to get it to work, but
not a huge amout (all the interfaces to the debug info are already there).

>
> >>Probably the ugliest think about lkcdutils is building it.  It really
> >>needs to use autoconf/automake.  (So does crash, BTW).  But I don't have
> >>a lot of reason to fix that because I'm not using it any more.  I might
> >>work on fixing crash, but I have a lot of other things on my plate right
> >>now.
> >>
> >>IMHO, lkcdutils doesn't need to exist any more.  Let Dave handle the
> >>crash dump support (with a little support from you) and use some simple
> >>tool for crash dump extraction like the one HP developed or lkcdtools.
> >>That way you can focus your energy on other things.
> >>
> >>
> >
> >Perhaps in the future...right now that is not an option (for us). There
are
> >various reasons why lkcdutils (lcrash) is our crash dump toolset of
choice.
> >A lot of these tie directly to support of our (SGI) systems and the
timing
> >of product releases. We will have to see how this entire space evolves
over
> >time. Right now, I'm just glad to see a higher level of activity and
energy
> >in this project.
> >
> >
> Fair enough, I understand how that goes :).

:]

Thanks for the input...

Tom



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl