----- Original Message ----- > > Hi Dave, > > > I notice there was some discussion around on enabling > the display function parameters feature for crash tool. > Like this one: > http://www.redhat.com/archives/crash-utility/2009-May/msg00016.html Yes, it seems to come up every few years. People have tried, but it has never come to fruition. > > Although the answer seems to be quite clear, it should be hard to > support such feature. But does this feature cannot be done anyway? > I think this feature would be great in assisting kernel debug. > > The main feature I require, first should be know each param's value > in the call stack. > Then it is better to know each call stack's param's name. > > Like for do_vfs_ioctl function, it is better to display as: > do_vfs_ioctl(filp=xxx, fd=xxx, cmd=xxx, arg=xxx) > > Do you have any idea on how this could be implemented? No I don't.

----- Original Message ----- > > Dave, > > > On Fri, Sep 21, 2012 at 9:44 PM, Dave Anderson < anderson(a)redhat.com > > wrote: > > > > > > ----- Original Message ----- > > > > Hi Dave, > > > > > > I notice there was some discussion around on enabling > > the display function parameters feature for crash tool. > > Like this one: > > http://www.redhat.com/archives/crash-utility/2009-May/msg00016.html > > Yes, it seems to come up every few years. People have tried, but it > has never come to fruition. > > > > > > Although the answer seems to be quite clear, it should be hard to > > support such feature. But does this feature cannot be done anyway? > > I think this feature would be great in assisting kernel debug. > > > > The main feature I require, first should be know each param's value in the call stack. > > Then it is better to know each call stack's param's name. > > > > Like for do_vfs_ioctl function, it is better to display as: > > do_vfs_ioctl(filp=xxx, fd=xxx, cmd=xxx, arg=xxx) > > > > Do you have any idea on how this could be implemented? > > No I don't. > > > > Sorry for asking the stupid question, but I notice that we could > get the structure member in crash by "struct" command: > > crash> struct stackframe > struct stackframe { > long unsigned int fp; > long unsigned int sp; > long unsigned int lr; > long unsigned int pc; > } > SIZE: 16 > > > I check the crash code, and find cmd_struct use gdb interface to > parse it out. > > > And the gdb itself seems already could parse out function argument[1], so could > we still use similar mechanism as the "struct" command to implement a "func" > command, which could shows the function declaration? You can either use the "whatis" command to get the function declaration: crash> help whatis NAME whatis - search symbol table for data or type information SYNOPSIS whatis [struct | union | typedef | symbol] DESCRIPTION This command displays the definition of structures, unions, typedefs or text/data symbols. ... crash> whatis do_vfs_ioctl int do_vfs_ioctl(struct file *, unsigned int, unsigned int, long unsigned int); crash> Or print it with "p", which gives you both the declaration and its virtual address: crash> p do_vfs_ioctl do_vfs_ioctl = $14 = {int (struct file *, unsigned int, unsigned int, long unsigned int)} 0xffffffff811247ec <do_vfs_ioctl> crash>

Dave

----- Original Message ----- > You can either use the "whatis" command to get the function > declaration: > > crash> help whatis > > NAME > whatis - search symbol table for data or type information > > SYNOPSIS > whatis [struct | union | typedef | symbol] > > DESCRIPTION > This command displays the definition of structures, unions, typedefs > or > text/data symbols. > ... > > crash> whatis do_vfs_ioctl > int do_vfs_ioctl(struct file *, unsigned int, unsigned int, long unsigned int); > crash> > > Or print it with "p", which gives you both the declaration and its > virtual address: > > crash> p do_vfs_ioctl > do_vfs_ioctl = $14 = > {int (struct file *, unsigned int, unsigned int, long unsigned int)} 0xffffffff811247ec <do_vfs_ioctl> > crash> > > That works. :) > However could it be possible to show the argument without only display its type? > The kernel is defining the do_vfs_ioctl as: > > int do_vfs_ioctl(struct file *filp, unsigned int fd, unsigned int cmd, unsigned long arg); > Could the "filp, fd, cmd, arg" be showed out? Anything from the output line could be selectively shown if you parse the gdb output with open_tmpfile() or open_tmpfile2() if necessary.

----- Original Message ----- > > > Do you mean if I want to display out something like: > int do_vfs_ioctl(struct file * filp, unsigned int fd, unsigned int cmd, long unsigned int arg); > I need to use the tmpfile to pass "filp, fd, cmd, arg" to "whatis"? > > But the reality is that I don't know how to let crash extract the four parameter name, > then how could I pass this info to the tmpfile? > > Also the interest of me is get the output as: > do_vfs_ioctl(filp, fd, cmd, arg); > The parameter's type may not need to be displayed as the whatis case. > > Thanks, > Lei Ah OK, I misunderstood your first question. As far as getting the parameter names themselves, there is no helper function that does that. There are two ways of accessing gdb functionality -- either: (1) a gdb command string can be issued unmodified via the gdb_pass_through() function, or (2) a specific pre-existing gdb helper function may be accessed via gdb_interface(), which ends up in the gdb_command_funnel() function in gdb-7.3-1/gdb/symtab.c. with respect to (1), ideally there would be some other gdb command string that you could pass unmodified to gdb to get what you want, but I don't know of any. With respect to (2), the gdb_command_funnel() function has a switch statement for a list of several pre-existing "req->command" definitions, but none of them pull out the actual names of text function arguments. I would guess that the argument name strings could be pulled out with a new gdb helper function, but you'd have to write it yourself.