Adding bit position to ptype

  Hi, I am having trouble looking up field offsets when reading disassembled text.
So I add an extra field to ptype:
(gdb) ptype WebCore::FrameLoader
type = class WebCore::FrameLoader {
  private:
    WebCore::Frame *m_frame bitpos: 0;
    WebCore::FrameLoaderClient *m_client bitpos: 32;
    WebCore::PolicyChecker m_policyChecker bitpos: 64;
    WebCore::HistoryController m_history bitpos: 3264;
    WebCore::ResourceLoadNotifier m_notifer bitpos: 3552;
    WebCore::SubframeLoader m_subframeLoader bitpos: 3584;
    WebCore::FrameLoaderStateMachine m_stateMachine bitpos: 3680;
    WebCore::IconController m_icon bitpos: 3712;
...

That helps me a lot to understand what "ldr r0, [r4, #408]" means.
---
 gdb/c-typeprint.c | 6 ++++++
 1 file changed, 6 insertions(+)
  

>>>>> ">" == lin zuojian <manjian2006@gmail.com> writes:

>> Hi, I am having trouble looking up field offsets when reading
>> disassembled text.  So I add an extra field to ptype:

Nice.

You might be interested in pahole.py.

>> diff --git a/gdb/c-typeprint.c b/gdb/c-typeprint.c
>> index 4edc9ec..9fbbc36 100644
>> --- a/gdb/c-typeprint.c
>> +++ b/gdb/c-typeprint.c
>> @@ -1110,6 +1110,12 @@ c_type_print_base (struct type *type, struct ui_file *stream,
>>  		    fprintf_filtered (stream, " : %d",
>>  				      TYPE_FIELD_BITSIZE (type, i));
>>  		  }
>> +		else if (!field_is_static (&TYPE_FIELD (type, i)))
>> +		  {
>> +		    /* print the bit pos.  */
>> +		    fprintf_filtered (stream, " bitpos: %d",
>> +		                      TYPE_FIELD_BITPOS (type, i));
>> +		  }
>>  		fprintf_filtered (stream, ";\n");

To be considered for acceptance all patches require a ChangeLog entry
and must pass regression testing -- which this one probably does not, as
it changes gdb's output by default.  Please see the contribution
instructions.

I think it would probably be better to add a flag to ptype to enable
this behavior.  Integrating all of the pahole behavior into ptype would
be even better, though I understand if you don't want to go this far.

thanks,
Tom
  

Hi Tom,
    Before posting the second patch, I may make your point clear first.
    Do you want me to add a flag to control this behavior?
    Thanks
--
Lin Zuojian
  

>>>>> ">" == lin zuojian <manjian2006@gmail.com> writes:

>>     Before posting the second patch, I may make your point clear first.
>>     Do you want me to add a flag to control this behavior?

Yeah, I think the behavior should be optional and should default to
"off".

I think it's best to consider this as a new feature -- so it would need
a new ptype flag, documentation, NEWS entry, and tests.  The bad news is
that this is much more work for you.  That's probably why nobody has
implemented it before.

Tom