----- 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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
