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

[Dave Anderson]

----- "Sharyathi Nagesh" <sharyath at in.ibm.com> wrote:

> >> 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.

It's not a new concept.  If the extensions/Makefile sees a "local.c" file,
it will then look for a "local.mk" file and invoke it.  I applied your
patch, and "make extensions" from the top-level directory works as expected
(although the compilation fails as expected):

  # make extensions
  gcc -nostartfiles -shared -rdynamic -o local.so local.c -fPIC -ldw -L ../../elfutils-0.137/libdw -I ../../elfutils-0.137/libdw -I ../../elfutils-0.137/libelf/ -DX86_64   -Wall; 
  local.c:8:23: error: libdw.h: No such file or directory
  local.c:9:19: error: dwarf.h: No such file or directory
  local.c:11:21: error: netdump.h: No such file or directory
  local.c:33: error: expected ‘)’ before ‘*’ token
  ...

> > 
> >> 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

The extensions/sial.mk file is the only example in the upstream tree.

Actually there are two alternatives:

(1) as you are doing now, put your local.c and local.mk and whatever other
    files you need into an existing extensions subdirectory, or 
(2) build a standalone package that only requires the crash-devel
    subpackage.

Alternative (2) allows you to create a standalone package that
uses the crash-devel subpackage, which only consists of the "defs.h"
file.  Doing it that way you don't need the complete crash source tree.
Your package is unique in that it currently needs "netdump.h"
for the vmcore_data structure.  I am not averse to moving that
structure declaration into "defs.h" if you want to go that route.

Check out the IBM crash-spu-commands-1.1-1.src.rpm package as an example
of alternative (2):

  http://riksun.riken.go.jp/pub/pub/Linux/cern/updates/slc5X/SRPMS/crash-spu-commands-1.1-1.src.rpm

In any case, that's easy enough to deal with in the future.
I'd just continue working in the extensions subdirectory for now.
 
> >> 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 opion we need
>   1. function to provide task context for the pid passed

That would be pid_to_context().

But more on that below...

>   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

The only register sets are found in the per-cpu NT_PRSTATUS notes in
the ELF header.  They don't exist for the other non-active tasks, and 
in fact, the older netdump format only contains a single ELF NT_PRSTATUS
for the crashing cpu task. 

Furthermore, if the kdump vmcore is compressed with "makedumpfile -c",
then the resultant dumpfile's unique non-ELF header doesn't even contain
those register sets.  

> -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

I don't know why that would be necessary.  When your cmd_local() function
is called without "-p <pid>", it should just default to the current context
which would have been set with the prior "set -c <cpu>", "set <task>" or
"set <pid>".  For that matter, why do you even need "-p <pid>"?  I'm not
clear on why you wouldn't be using the current context all of the time?

It appears that your mechanism will only work if the target task is
an active task whose register set is contained in the ELF header.
So when your command is called, it seems like it would simply need to
first determine "can I handle this context?", and if not, just bail out.

Dave