[Crash-utility] Faster iteration on list of struct.field

[Dave Anderson]

----- Original Message -----
> Dave Anderson wrote on Fri, Feb 07, 2020:
> > > Following up with patch, with a couple of remarks:
> > >  - I had to change member_to_datatype() to use datatype_info() directly
> > > instead of MEMBER_OFFSET(), to fill dm->member_size. I'm not sure if
> > > this will have any side effects, but things like 'struct foo.a,b' still
> > > work at least. You might have a better idea of what to check.
> > 
> > Hmmm, I'd prefer to keep the member_datatype() behavior as it is, and
> > not have datatype_info() re-initialize the incoming dm.  (except for
> > the setting of dm->member).  Maybe have a different flag for gathering
> > the size as you have, and keep the original functionality the same?
> > Or alternatively, leave the call to member_datatype() as-is, and if
> > do_datatype_addr() sees SHOW_RAW_DATA, additionally call MEMBER_SIZE()?
> 
> Ok, I just did that to save an extra gdb call as I was assuming that was
> slow, but it would probably be acceptable to call into gdb twice except
> for intellectual satisfaction... :)
> 
> Alternatively, have member_to_datatype() declare a temporary dm, pass
> that to datatype_info, and fill only dm->member_size ?
> I find it a bit weird to fill only member_offset and not the size...
> 
> Actually, for do_datatype_addr(), I'm pretty sure we never use the
> member_offset at all -- I just replaced member_to_datatype() by
> something that just assigned the member to dm->member and things just
> work for anything I could try (struct foo, struct foo.member, struct
> foo.member1,member2, struct foo.member1.innermember, struct -o foo,
> struct -o foo.member...)

I'm not following, your SHOW_RAW_DATA patch bumps the incoming addr by
dm->member_offset right?  Or do you mean in the normal case?  You are 
probably right there.

> 
> 
> > >  - I'm only passing ANON_MEMBER_QUERY to member_to_datatype() in the
> > > non-raw case.
> > 
> > I think you mean just the opposite...
> 
> woops, I meant what I wrote here, the code I sent is wrong -- we're not
> getting the member_size in the ANON_MEMBER_QUERY so I didn't want it for
> a first approach.
> 
> > All of the ANON_xxx macros were added for getting information for members
> > that are declared inside of anonymous structures within a structure, where
> > where the generic datatype_info() call fails.  In those cases, the request
> > gets directed to a gdb print command within anon_member_offset().  There is
> > no support for getting the size of such a member, so MEMBER_SIZE() would
> > fail.  So I don't think this feature would work for those types of members,
> > and would need some kind of ANON_MEMBER_SIZE() and accompanying
> > anon_member_size() functionality.
> 
> Hm, yeah, probably want to support these too.
> 
> anon_member_offset tricks gdb with the usual "&((type*)0)->member", we
> could get the size by printing the same "+1" and computing the
> difference.
> 
> Can get it in one call with casts, but that's not exactly pretty...
> "(u64)(&((type*)0)->member + 1) - (u64)&((type*)0)->member"...
> 
> Would that work for you?

I'd prefer to put it a separate function and macro, i.e., a new ANON_MEMBER_SIZE()
macro and accompanying anon_member_size(), just to follow convention.

Dave