Created attachment 6068 [details] Display C struct field offsets For figuring out where things will be on a cache line (among other things), it would be useful to be able to display the byte offset of each field in a C/C++ struct. That in itself seems pretty straightforward -- I'll attach a patch that does just that -- but I can't see a good way of enabling it. I wouldn't want it to be the default, since it's just too noisy. I would want it to be controlled by 'set print field-offsets on' or an optional parameter to 'ptype' or something. But it appears that typeprint.c only passes an integer 'show' parameter to the language-specific type printers. I could overload 'show' to be a set of flags (the existing 1,0,-1 would be full,summary,short, and I would have a new fields option to or in), but that would require updating all languages (and would break external compatibility, if there is such a thing.) What would be the best way to implement something like this?
(In reply to comment #0) > Created attachment 6068 [details] > Display C struct field offsets > > For figuring out where things will be on a cache line (among other things), it > would be useful to be able to display the byte offset of each field in a C/C++ > struct. You may want to look at pahole.py as well: http://permalink.gmane.org/gmane.comp.gdb.patches/58385 > That in itself seems pretty straightforward -- I'll attach a patch that does > just that -- but I can't see a good way of enabling it. I wouldn't want it to > be the default, since it's just too noisy. I would want it to be controlled by > 'set print field-offsets on' or an optional parameter to 'ptype' or something. > But it appears that typeprint.c only passes an integer 'show' parameter to the > language-specific type printers. I could overload 'show' to be a set of flags > (the existing 1,0,-1 would be full,summary,short, and I would have a new fields > option to or in), but that would require updating all languages (and would > break external compatibility, if there is such a thing.) > > What would be the best way to implement something like this? There is no external compatibility, you can change the API with impunity. I would suggest a new flag to ptype, then passing around a "const struct ptype_options *" to all functions needing it, where ptype_options is a new struct you create. It is more typing to add this kind of thing, but it seems best to me, since it allows for future changes. We did this kind of thing for value printing a while ago...
FWIW, we now have struct type_print_options on the trunk.
Now in since https://sourceware.org/ml/gdb-patches/2017-11/msg00435.html aka commit 7c1618381fdaa0697a211721ac31844f884797ac Author: Sergio Durigan Junior <sergiodj@redhat.com> Date: Mon Nov 20 16:34:59 2017 -0500 Implement pahole-like 'ptype /o' option I think this made it into 8.1, so I'm marking it that way.