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

[Dominique Martinet]

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 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?

-- 
Dominique