[Crash-utility] Re: crash enhancements proposal

Maneesh Soni wrote: Certainly a welcome task. I suggest segregating the code in a separate file (as done with lkcd_x86_trace.c), and the new entry point can simply be plugged into machdep->back_trace function pointer at init time. There should also be an "out" to allow it to be set back to use the current x86_64_low_budget_back_trace_cmd(). Also, if it doesn't support -fomit-frame-pointer, it's not worth doing. I don't quite understand how moving code to libraries is going to achieve the goal here. Things in some of the various *_init() functions could certainly be streamlined (or skipped) in order to make it more likely to make it to the first prompt. For example, the task table initialization could be made to simply fill in the context data for just the panic task. (But it almost sounds like you just want to use gdb alone for the minimal set of commands you've listed?) As far as "re-writes" are concerned, please keep in mind the necessity of backwards-compatibility. I'd much rather keep the current code -- that's known to work -- in place, and if you come up with something new, or re-shuffled, make it only callable when the kernel is of a known kernel version or later. The point is, let's not just re-invent the wheel just for purpose of re-inventing the wheel. I don't particularly like this suggestion. (I thought we just went through a problem where Ubuntu kernels don't even have kernel headers?) As far as code reuse, we already do that in a number of places, so I guess that's OK. And there is just never seems to be a "one-size-fits-all" set of kernel functions/macros that covers all bases over the life of the kernel and each processor type. But as always, I'm open to suggestion. Not a bad idea... OK. Often this gets recognized already, or if things are horribly corrupted, the session won't even come up. Have at it... Given the x86_64 usage of registers for passing args, good luck. Again, I guess it might be nice. Talk to gdb -- that's where it all comes from... For any text address, gdb has the associated line number data. It often looks confusing because the text comes from a header macro or inline or whatever. I don't know what you can do about that. Needs more of a description... I thought crash was a kernel [crash/live-system] analyzer? You currently can add user-space debug data with "add-symbol-file", which loads the debug data and symbols into gdb. I have done this kind of thing, but it's been an "almost-never" kind of situation, where I've wanted to display a user program's data structure. But if you want to start throwing in this kind of user-space stuff, please just keep it segregated. Not clear on what "establishing" CPU registers means. We already dump exception frames. I guess you mean to be able to use a register connotation in certain commands, as opposed to the address contained in the register? That's potentially messy, because it puts processor-specific stuff in processor-neutral code. As far as the LDT, GDB, task gates formatting, that's fine. No way -- we've been through this before. It is essentially a complete re-write. If you want this, make a new command entirely. I've made my personal feelings on these kinds of things before, which is to take a "minimalist" approach. Every new bell and whistle is virtually guaranteed to break as the kernel churns. And they all require an additional support burden. If I had my druthers, crash would have less rather than more at this point. But I understand that this has become a community project, and with the few exceptions above, I'm open to all patch suggestions. Thanks, Dave