This is the mail archive of the elfutils-devel@sourceware.org mailing list for the elfutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC]: Feature to display local arguments and variables


Dave
    Thanks for your feedback, we are currently working on stack 
unwinding and including support for x86 , we will address these as we go by

Dave Anderson wrote:
> ----- "Sharyathi Nagesh" <sharyath@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?
Yes, found the Makefile under extensions is not called due to this, we 
faced this issue with crash 4.0.7.7 didn't try with latest crash though.
> 
>> 2. create a symbolic link to netdump.h under extensions/
> 
> You should be able to do that in your local.mk file.
Ok, sure will take care of that. Please let us know of any reference 
*.mk file that is used. will help as this will need to take care of 
library dependencies in this 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.
Yes you are right in a way most of the time top most stack frame will be 
these functions which wont be of much help in debugging. Only solution 
we found is to support stack unwinding
> 
> 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?
There is lot of architecture dependency code involved in this 
implementation and we thought the best way to take it further is to 
handle them one by one. Will make best efforts to support x86_64 arch 
too based on time constraints
>> 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)
yes you are right initialize_local() function needs to handle it.
For -p option we need
  1. function to provide task context for the pid passed
  2. Current register context for the process, for Active process we 
could get from ELF Notes, if there is a way to access register set for 
these process it would be helpful

-c option allows user to shift context. If user changes active CPU via 
set -c <new CPU>, local -c will allow user to move current local context 
to that particular cpu context.

Please Let us know your thoughts on this implementation
> 
>> 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? 
> 
It can be, basically it will be nested tags and if it a structures 
containing another structure or a union we need to go through each Sub 
element and find its data type and print its value. will work more on it 
to see what can be done

>> 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.
Sure that can be handled
> 
> Anyway, it looks promising on paper!
> 
> Thanks,
>   Dave
> 
Thanks Dave for the inputs
Regards
Sharyathi N

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]