[Crash-utility] Re: [RFC]: Feature to display local arguments and variables
----- "Sharyathi Nagesh" <sharyath(a)in.ibm.com> wrote:
Hi
We have implemented this piece of code to provide, crash tool,
capability to display local variables and arguments. We would kindly
request you to provide your feedback and guidance on this code so that
we can take it further
When I get a chance I'll reserve a ppc64 machine to give this a go.
But for now, I've just got a few questions and suggestions.
How to Build/Requirements
1. Enable compiling extends option in main Makefile
You mean to just enter "make extensions", right?
2. create a symbolic link to netdump.h under extensions/
You should be able to do that in your local.mk file.
3. This feature makes use of libelf and libdw libraries provided by
elfutils package.
4, This feature is implemented as an extend, local.so library needs to
be loaded once crash prompt is available
Features
1. Currently it has feature to display arguments/locals of top most
stack frame. ex usage: local params or local locals
What function would be considered the "top most" stack frame, say if
panic() were called, i.e., when crash_kexec() gets called with a NULL
"regs" argument? It appears that it would be crash_kexec() itself.
On the other hand, most dumps are generated from die(), but the regs
have been passed through several functions, so it's not clear to me
what you would see.
For those of us who are ppc64-machine-challenged, a few examples would
have been helpful...
2. Currently code can analyze only ppc64 dumps
3. It displays the current address of the local variables ( and some
times direct values when the variables are stored in register and not in
stack frame)
4. In case of code optimization, variable information is not available
at that time printing "Failed to fetch information" (This is in
accordance with gdb out put)
TBD
1. Stack unwinding code is still need to be implemented
2. Support for x86 dumps is still not provided
BTW, have you explicitly left out x86_64?
3. Context switching via -r command still needs to implemented
BTW, the "placeholder" code in cmd_local() for -p and -r would be
disastrous because they modify a context structure with a totally
different pid. What you'll want to do is update local->tc with a
pointer to the context of the entered pid argument. (There's helper
functions to do that)
Note: We were planning to display the variable values instead of
addresses as we are doing currently, but it adds up to additional
challenges in terms of typecasting the variables, in case it is array or
structure, so for the time being we are printing only address and expect
user to dump contents using rd command. Suggestions here will be very helpful.
Presumably the user will know what the local data types are, and can
simply display them using the "struct <datatype> <address>"
command.
Using rd is fine, but may be unnecessarily primative. But anyway,
are you saying that the local variable data types cannot be determined
from some dwarf interface?
Attaching the code...but the Code is not extensively tested
please let us know your thoughts
Another minor nit -- I'd prefer that a new function be added to
netdump.c similar to get_kdump_vmcore_data() that you can use
for "real" netdump dumpfiles -- if you are planning to actually
planning to support netdump dumpfiles. Just create a new
get_netdump_vmcore_data() instead of making the structure global.
Anyway, it looks promising on paper!
Thanks,
Dave