Dwarfparse in linux-support should include underlying type for bitfields

[GoogleCodeExporter]

Hiya,

So just a quick reminder that BitField now support a native_type parameter, 
which should be one of the keys in the native_types dict for the profile in 
question, and should therefore produce the following types of output:

['BitField', {'end_bit':32, 'start_bit':24, 'native_type':'unsigned long long'}]

Thanks!  5:)

Original issue reported on code.google.com by mike.auty@gmail.com on 17 Mar 2011 at 12:43

[GoogleCodeExporter]

Original comment by mike.auty@gmail.com on 21 Jun 2011 at 6:11

• Added labels: Milestone-1.5.x

[GoogleCodeExporter]

update, attc will double check, but prob fixed

Original comment by michael.hale@gmail.com on 15 Dec 2011 at 9:21

[GoogleCodeExporter]

Any news on this?

Original comment by mike.auty@gmail.com on 23 Jan 2012 at 2:38

[GoogleCodeExporter]

Dropping the Milestone for this because unfortunately it doesn't look like 
linux will make it into the next release...  5:(

Original comment by mike.auty@gmail.com on 26 Mar 2012 at 12:55

• Removed labels: Milestone-1.5.x

[GoogleCodeExporter]

Ok, since we've now got the linux-trunk branch, and DwarfParse is part of the 
utils package, I've produced a patch.  Could someone who knows exactly what's 
going just check that it's ok please?  This is quite a long standing bug, and 
I'd really like to get it closed off.

I can't tell if the BitField size could ever be something odd like 7, or worse 
9.  Could someone verify that BitFields never go over 8 bytes, and also whether 
they're likely to be odd or not?  If it's all good I can apply this and mark it 
as fixed...

Original comment by mike.auty@gmail.com on 15 May 2012 at 10:52

Attachments:

• bitfield-fix.patch

[GoogleCodeExporter]

Original comment by mike.auty@gmail.com on 15 May 2012 at 11:06

• Added labels: Milestone-2.1.x

[GoogleCodeExporter]

Hey guys, here's something I sent in email to I think attc and bdg and maybe 
scudette a long time ago. It might be helpful, if not just ignore it ;-)

"""
How's it going? I used dwarfparse.py from the linux-support branch on a MIPS 
ELF. It worked good, but I had to make the following changes to prevent stack 
dumps. I don't really know the consequences of these changes - just happened to 
try them and it seemed to fix the problem and give me usable vtypes. So I 
figured I'd let you know in case its something that others may run into. 

Hope all is well!
MHL

===================================================================
--- dwarfparse.py    (revision 1063)
+++ dwarfparse.py    (working copy)
@@ -222,7 +222,7 @@
                 anons += 1
             name_stack[-1] = (name_stack[-1][0], name)
             id_to_name[parsed['id']] = [name]
-            vtypes[name] = [ int(parsed['data']['DW_AT_byte_size']), {} ]
+            vtypes[name] = [ int(parsed['data'].get('DW_AT_byte_size', 1)), {} 
]
         elif parsed['kind'] == 'DW_TAG_array_type':
             name_stack[-1] = (name_stack[-1][0], parsed['id'])
             id_to_name[parsed['id']] = parsed['data']['DW_AT_type']
@@ -250,7 +250,7 @@
         elif parsed['kind'] == 'DW_TAG_const_type':
             id_to_name[parsed['id']] = parsed['data'].get('DW_AT_type', ['void'])
         elif parsed['kind'] == 'DW_TAG_typedef':
-            id_to_name[parsed['id']] = parsed['data']['DW_AT_type']
+            id_to_name[parsed['id']] = parsed['data'].get('DW_AT_type', 
['void'])
         elif parsed['kind'] == 'DW_TAG_subroutine_type':
             id_to_name[parsed['id']] = ['void']         # Don't need these
         elif parsed['kind'] == 'DW_TAG_variable' and parsed['level'] == '1':
"""

Original comment by michael.hale@gmail.com on 16 May 2012 at 4:36

[GoogleCodeExporter]

Since this is for linux, which won't be making an appearance until 2.2, I'm 
going to push the milestone back.

Original comment by mike.auty@gmail.com on 22 May 2012 at 1:43

• Added labels: Milestone-2.2.x
• Removed labels: Milestone-2.1.x

[GoogleCodeExporter]

This was fixed last august in r2184

Original comment by michael.hale@gmail.com on 1 Feb 2013 at 4:35

• Changed state: Fixed