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?