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

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