Alex, Just send me a full patch against symbols.c, since that's the only file that you'll need to patch from this point on. I'm happy with the state of the other files.
Thanks, Dave Sent from my ASUS Pad Alexandr Terekhov <[email protected]> wrote: >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 > >-- >Crash-utility mailing list >[email protected] >https://www.redhat.com/mailman/listinfo/crash-utility > -- Crash-utility mailing list [email protected] https://www.redhat.com/mailman/listinfo/crash-utility
