LLDB reads incorrect memory ranges when displaying bitfields when reading bits from file memory.

Bitfields were not correctly describing their offsets within the integer that they are contained within. If we had a bitfield like:

struct MyStruct {
  uint32_t a:8;
  uint32_t b:8;
};
        
ClangASTContext::GetChildCompilerTypeAtIndex would say that child a and b had the following values in their respective ValueObjectChild objects:

name byte-size bit-size bit-offset byte-offset-from-parent
==== ========= ======== ========== =======================
"a"  4         8        0          0
"b"  4         8        0          1

So if we had a "MyStruct" at address 0x1000, we would end up reading 4 bytes from 0x1000 for "a", and 4 bytes from 0x1001 for "b". The fix for this is to fix the "child_byte_offset" and "child_bitfield_bit_offset" values returned by ClangASTContext::GetChildCompilerTypeAtIndex() so that now the table looks like:

name byte-size bit-size bit-offset byte-offset-from-parent
==== ========= ======== ========== =======================
"a"  4         8        0          0
"b"  4         8        8          0

Then we don't run into a problem when reading data from a file's section info using "target variable" before running. It will also stop us from not being able to display a bitfield values if the bitfield is in the last bit of memory before an unmapped region. (Like if address 0x1004 was unmapped and unreadable in the example above, if we tried to read 4 bytes from 0x1001, the memory read would fail and we wouldn't be able to display "b").

<rdar://problem/27208225> 

llvm-svn: 274701

0 files changed, 0 insertions, 0 deletions