----- Original Message ----- > 2. anonymous member, "struct page.private", will be showed together with > its offset Sorry -- but doing that redefines the "struct" command output for both named members and anonymous members. The "struct -o" option should be used to prepend the offset. Can you re-work the patch so that it behaves the same way as it currently does?

At 2012-3-6 0:25, Dave Anderson wrote: > > > ----- Original Message ----- >> Hello Dave, >> >> I have realized the function to display anonymous members of >> struct/union. There are three changes, which are listed below, and I >> will take "struct page" for example. >> >> 1. anonymous members will be showed when using "struct page" > > That's nice... > >> 2. anonymous member, "struct page.private", will be showed together with >> its offset > > Sorry -- but doing that redefines the "struct" command output for both named > members and anonymous members. The "struct -o" option should be used to prepend > the offset. Can you re-work the patch so that it behaves the same way > as it currently does? > >> 3. anonymous member with the address of the structure, "struct page.private xxx", will be showed. >> >> About the implementation, gdb code is changed, which is used to change >> the output of the gdb command, "ptype ...". And function >> "arg_to_datatype" is also modified to analyze anonymous member. > > I'm presuming (but not sure) that the change to anon_member_offset() to use > open_tmpfile2() is because your patch introduces a new potential path to > anon_member_offset() that would be inside a open_tmpfile()/close_tmpfile() > region? Is that correct? Exactly, when showing struct.member, function do_datatype_declaration() is involved. And in this function, open_tmpfile() is called. Then after the call of open_tmpfile() and before the call of close_tmpfile(), show_member_offset(), in which I added ANON_MEMBER_OFFSET, is called. This macro will call anon_member_offset(). So I change to use open_tmpfile2() to prohibit to recursive usage. > > The change to gdb's c_type_print_base() function is interesting -- do > you consider that a bug in gdb, or do you think they have a reason > for doing it the way it's done now? I ask because gdb has several > structure-printing optional variables, so I'm kind of surprised that > it's hard-wired to behave the way it does. The original gdb will display at most three levels of structure in depth when using command "ptype ..." without concerning the anonymous member. In my patch, I modified the calculation of "show", which is used to indicate the level. The show will not decrease 1, using my patch, when anonymous structure appears. Take the below struct for example: type = struct a { struct { struct { union { struct { ... }; ... }; }; }; }; All will be displayed using my patch. And the original gdb will only display like: type = struct a { struct { struct {...} }; }; The original gdb, in my opinion, shows simplicity. And comes to the aspect of source code, nothing obviously shows the differentiation. These are all that I can figure out until now.