On Tue, May 19, 2015 at 12:14:49PM -0400, Dave Anderson wrote:
I've run into three problems dealing with embedded arrays.
First, should array elements inside an embedded structure be
selectable? For example, the task_struct has an embedded
task_rss_stat structure:
.........
crash> task -R rss_stat.count[1]
PID: 11722 TASK: ffff8801073da5d0 CPU: 2 COMMAND: "crash"
task: invalid structure member reference: rss_stat.count[1]
crash>
Is that expected behavior?
Yes, the new logic consider structure
count = {0, 0, 0}
in the same way as scalar (you can find the corresponding comment within
parser branches.
+ if ( p && (*s_e != '{' || (*s_e == '{' &&
buf[len] == '}'))) {
+ /* Scalar or one-line array
+ * next = 0x0
+ * or
+ * files = {0x0, 0x0}
+ */
+ strcpy(current->value, s_e);
+ if (trailing_comma) ALLOC_NEXT_ELEMENT;
+ }
Since this type of array is short, I wasn't sure whether it's necessary to
access its elements or not.
But for some reason, it fails to accept the "pid_link.pid"
member:
crash> task -R pids[1].pid
PID: 11722 TASK: ffff8801073da5d0 CPU: 0 COMMAND: "crash"
task: invalid structure member reference: pids[1].pid
This behavior is incorrent, I will check it.
And third, this behavior also doesn't seem correct. Here again I
select
just the first element of the task_struct.pids[] array:
crash> task -R pids[0].node
PID: 11722 TASK: ffff8801073da5d0 CPU: 2 COMMAND: "crash"
pids[0].node = {
next = 0x0,
pprev = 0xffff880105fc9888
},
But it allows me to leave off the "pids[x]" reference, and if so, it defaults
to the first member of the array:
crash> task -R pids.node
PID: 11722 TASK: ffff8801073da5d0 CPU: 0 COMMAND: "crash"
pids.node = {
next = 0x0,
pprev = 0xffff880105fc9888
},
Should it reject that syntax?
Yes, it should. I will fix it.
And again, since you've started updating my patch, what is the best way
to provide these fixes?
Thanks,
Alexandr