----- Original Message ----- > > > ----- Original Message ----- > > On Tue, 4 Aug 2015 16:57:35 -0400 (EDT) > > Dave Anderson <anderson(a)redhat.com&gt; wrote: > > > > > > > > > > > ----- Original Message ----- > > > > > > > > Michael > > > > > > > > OK, so it would seem to be somewhere in the trail from enumerator_value() > > > > into the gdb_command_funnel() via the GNU_GET_DATATYPE req->command in > > > > datatype_info(). > > > > > > > > I'm having a hard time provisioning an s390x machine internally at this time. > > > > When I get one, I'll see if the problem has been there all along. > > > > > > > > Dave > > > > > > > > > > Michael, > > > > > > I finally got access to an s390x and I see the same thing. In fact it also > > > happens on a RHEL6 2.6.32-based kernel, so it appears it's always been an > > > issue. I'll look into it tomorrow. > > > > Great, thanks! > > > > Michael > > > > The problem is in gdb-7.6/gdb/symtab.c, in the eval_enum() function that > gets created/added by the crash utility's gdb-7.6.patch: > > static void > eval_enum(struct type *type, struct gnu_request *req) > { > register int i; > int len; > int lastval; > > len = TYPE_NFIELDS (type); > lastval = 0; > > for (i = 0; i < len; i++) { > if (lastval != TYPE_FIELD_BITPOS (type, i)) { > lastval = TYPE_FIELD_BITPOS (type, i); > } > if (STREQ(TYPE_FIELD_NAME(type, i), req->name)) { > req->tagname = "(unknown)"; > req->value = lastval; > return; > } > lastval++; > } > } > > The function is only used for anonymous (nameless) enums like MM_ANONPAGES. > It simply walks through the enumerator fields and looks for a matching string, > having captured the value of each enumerator in "lastval". This function hasn't > changed, and has simply been forward-ported with each upgrade of gdb. What has > changed, though, is gdb itself between gdb-7.3.1 and gdb-7.6, which added a new > TYPE_FIELD_ENUMVAL() macro, which should replace the two instances of > TYPE_FIELD_BITPOS() above. > > I'm thinking that this is an endian issue, where the generic TYPE_FIELD_BITPOS() > macro works OK for little-endian machines, and probably has always failed for big-endian > machines. I'm provisioning a big-endian ppc64 to verify that. (Although I'm not sure > what macro should have been used in the older gdb versions that didn't have > a TYPE_FIELD_ENUMVAL()?) > > Anyway, that's the resolution -- I'll be updating the gdb-7.6.patch > upstream later today > or tomorrow. > > Dave FYI, this is an endian issue. Fortunately very few anonymous enums are utilized by the crash utility: MM_ANONPAGES/MM_FILEPAGES (2.6.34 and later) ZONE_ALL_UNRECLAIMABLE (pre-2.6.34) WORK_CPU_UNBOUND (2.6.36 and later) The ZONE_ALL_UNRECLAIMABLE enum value is 0, so that works OK by mistake. The WORK_CPU_UNBOUND enum is used for kt->kernel_NR_CPUS, but if it gets set to 0 by mistake, all users of it in the crash utility will utilize the per-arch NR_CPUS value compiled into the crash utility, so it's a benign problem. So what this boils down to is a faulty "ps" RSS value when analyzing 2.6.34 and later big-endian kernels. Dave