----- Original Message -----
>
>
> ----- Original Message -----
> > On Tue, 4 Aug 2015 16:57:35 -0400 (EDT)
> > Dave Anderson <anderson@xxxxxxxxxx> 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
fghfghfgh
>
>
>
>
>
>
>
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
