[Crash-utility] Miscellaneous fixes/enhancements to crash 4.0-2.10

[Dave Anderson]

There were a couple things in this patch set which I did not
accept, or changed a bit.  One minor, one major...

One thing was this proposed patch to x86.c:

--- crash-4.0-2.10/x86.c        2005-11-07 07:44:06 -08:00
+++ crash-4.0-2.10-new/x86.c    2005-11-07 18:57:19 -08:00
@@ -683,8 +683,7 @@

         if ((machdep->flags & OMIT_FRAME_PTR) ||
            bt->debug ||
-           (bt->flags & BT_FRAMESIZE_DEBUG) ||
-           !(bt->flags & BT_OLD_BACK_TRACE)) {
+           (bt->flags & BT_FRAMESIZE_DEBUG)) {
                 lkcd_x86_back_trace(bt, 0, fp);
                 return;
         }

Regardless whether the kernel was built with -fomit-frame-pointer
or not, the LKCD-derived backtrace code is used by default, unless
the "bt -o" flag is used.  That fact was not advertised in the bt
help page, but it is now.  However, the old backtrace code will never
be used if the kernel was build with the -fomit-frame-pointer flag,
because it simply fails miserably.  So int that case, "bt -o" is
ignored.

However, in a case where the target kernel was built without the
-fomit-frame-pointer flag, and you'd like to use the "old" backtrace
code without having to enter the -o option every time, I have added
a "bt -O" option, which will toggle the backtrace behavior flag;
the first time that it's entered, all backtrace commands will use
the old backtrace code automatically; subsequent "bt -O" commands
will toggle it back and forth.  Again, this feature is useless
and ignored if the kernel was built with -fomit-frame-pointer.

I also did not feel comfortable accepting the extension-keyword
stuff.  While I do recognize that it would be useful to be
able to dynamically determine what extension modules to load,
I don't feel the extend command should be encumbered with the
job, but rather such an implementation-specific chore should
be handled by an instance of extension library code.

For that reason I exported both the load_extension() and
unload_extension() functions so that extension library code
could use them to in turn load other extension libraries.

The call to load_extension() could be made from either the
_init() function or from an extension command.  At those
points in time, the "first" extension library will have all
the information (kernel version, crash version, dumpfile,
etc.) at its disposal, and then can make the decision as to
what additional libraries to load.

The first extension library can either be left in place,
or, if all of the load_extension() calls are made during its
_init() function -- and its register_function() neglected --
that first library will be immediately unloaded.  For example,
the default _init() function looks like this:

_init() /* Register the command set. */
{
        register_extension(command_table);
}

It could be changed to do this:

_init() /* Don't register a command set -- load other extensions... */
{
     /* figure out what extensions to load here */

     go_figure();

     /* and then load them... */

     load_extension("this.so");
     load_extension("that.so");
}

Since the "extend" of the initial library above is being
done with doing a register_extension(), then crash will
immediately unload it.  So one "extend" command can lead
to a chain of library loads.

Alternatively, the command within the initial extension
library can be called, and based upon what is passed
into to it, it can load further libraries.

Dave


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20051110/d9b7ead3/attachment.htm>