Re: [Crash-utility] Faster iteration on list of struct.field
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