[Crash-utility] [PATCH] add -s option for struct command

[Dave Anderson]

----- Original Message -----
> Hello Dave,
> 
> The patch attached with this mail is to add "-s" option for struct
> command. The output is like below.
> 
> crash> page.private,_mapcount.counter,lru.next -s ffffea0000000850
> 0       -1      0xffffea0000000878
> crash> page.private,_mapcount.counter,lru.next -s ffffea0000000850 -h
> 0x0     0xffffffff      0xffffea0000000878
> 
> There are three features provided by the patches.
> 
> 1. the data can be output in one line, easier to be parsed
> 
> 2. it is extremly faster than original struct command and print command.
> When using command like "struct xxx.yyy -s < address_list", if there are
> lots of addresses in the file, address_list, the original struct command
> will spend several minutes and even several hours. But the patch will
> reduce the time to several seconds.
> 
> 3. submember can also be output, like "_mapcount.counter" int the above example
> 
> P.S.
> The first patch is used to modified gdb. It add a command called
> "printm", which can output the relative information of a struct's
> member.

In our original discussions, i thought that I had made it clear that
the introduction of a new option paradigm with submembers could be
avoided by using, for example, "page._mapcounter" instead of having
to enter "page._mapcount.counter"?  This option makes the struct
command seemingly violate its own rules, and really confuses things.
For example, with your patch, a user would see things like this:

 crash> page._mapcount.counter ffffea0000000508 -s
 -1      
 crash> page._mapcount.counter ffffea0000000508
 struct: invalid format: page._mapcount.counter
 crash> page._mapcount ffffea0000000508 
     _mapcount = {
       counter = -1
     }
 crash> page._mapcount ffffea0000000508 -s
 struct: invalid data structure reference page._mapcount
 crash>

I had suggested that you look into the get_member_data() function
in to the gdb/symtab.c file to access the member offset and size
values.

I also don't like the idea of modifying the prototype of
the stalwart print_command_1() gdb function, and the creation 
of a new gdb command.  Whenever there is a need to update the
embedded gdb version, patches like this can be problematic.
I would prefer that you create a new "GNU_XXXX" #define,
similar to GNU_GET_SYMBOL_TYPE, pass the request through
the gdb_command_funnel switch statement, and write a new
standalone function to accomplish what you have done in the
print_command_1() function. 
 
Dave