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

[Dominique Martinet]

Dave Anderson wrote on Fri, Feb 07, 2020:
> > 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.

Yes, I meant the normal case does not seem to use the result of
member_to_datatype() at all, except for it setting dm->member to
memberlist[i]

Sorry, I'm just mostly thinking out loud, it's just annoying me to call
datatype_info twice when most of the time it will get both offset and
size filled in.
I just tried and with 1000 elements time spent here goes up from 0.79s
to 0.97s but that still is very acceptable compared to... 132.30s for
the version without -r.
It's the stingy part of me that doesn't like doing the same gdb call
twice :)


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

Yes, I meant doing that in a new function, was just worried the
size computation is a bit too convoluted.

I will do as you suggested and submit a new patch when I find some time
to cleanup what I have.


Cheers,
-- 
Dominique