[Bug 47743] New: LLDB displays wrong values for packed bitfields

Bug ID 47743
Summary LLDB displays wrong values for packed bitfields
Product lldb
Version unspecified
Hardware All
OS All
Status NEW
Severity normal
Priority P
Component All Bugs
Assignee lldb-dev@lists.llvm.org
Reporter cameron@moodycamel.com
CC jdevlieghere@apple.com, llvm-bugs@lists.llvm.org

When an 'unsigned' bitfield is in a packed structure, its bits may straddle two
aligned dwords in memory.

LLDB calculates the value by reading a single dword from the byte offset of the
first unsigned, then shifting and masking using the bitfield offset/size.
However, when the value straddles two unsigned dwords, the byte offset + bit
offset + size extends past the end of the first dword, and the displayed value
is cut off (missing trailing bits).

To reproduce on a little-endian machine:

struct __attribute__((packed)) foo
{
        unsigned : 31;
        unsigned u11Sample : 11;
        unsigned : 22;
};

__attribute__((noinline))
int quux(struct foo* f)
{
        // break here and inspect f->u11Sample
        // the value should be 0x50, but it's not displayed as such
        return f->u11Sample;
}

int main()
{
        struct foo f = { 0 };
        f.u11Sample = 0x50;
        return quux(&f);
}

To reproduce on a big-endian machine use this struct definition instead:

struct __attribute__((packed)) foo
{
        unsigned : 22;
        unsigned u11Sample : 11;
        unsigned : 31;
};

As a starting point for whoever wants to investigate this, put a breakpoint on
'valobj->GetData(data, error);' (near line 91) in TypeFormat.cpp. Observe the
data read, as well as the
m_byte_offset/m_bitfield_bit_size/m_bitfield_bit_offset in valobj (it's of type
ValueObjectChild).

labath@google.com changed bug 47743

What | Removed | Added |

Comment # 3 on bug 47743 from labath@google.com

I have a fix up at [https://reviews.llvm.org/D88992](https://reviews.llvm.org/D88992). Could you please check
whether that fixes your problem? (The problem I ran into triggers in only very
specific circumstances, but judging by your description, you may have run into
something more generic.)