[all-commits] [llvm/llvm-project] a6a547: [lldb][DWARFASTParserClang] Prevent unnamed bitfie...

[Michael Buch via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: a6a547f18d99f0b0bf5ffac55443d687200f972d
      https://github.com/llvm/llvm-project/commit/a6a547f18d99f0b0bf5ffac55443d687200f972d
  Author: Michael Buch <michaelbuch12 at gmail.com>
  Date:   2024-09-12 (Thu, 12 Sep 2024)

  Changed paths:
    M lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
    M lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
    M lldb/test/Shell/SymbolFile/DWARF/no_unique_address-with-bitfields.cpp

  Log Message:
  -----------
  [lldb][DWARFASTParserClang] Prevent unnamed bitfield creation in the presence of overlapping fields (#108343)

This bug surfaced after https://github.com/llvm/llvm-project/pull/105865
(currently reverted, but blocked on this to be relanded).

Because Clang doesn't emit `DW_TAG_member`s for unnamed bitfields, LLDB
has to make an educated guess about whether they existed in the source.
It does so by checking whether there is a gap between where the last
field ended and the currently parsed field starts. In the example test
case, the empty field `padding` was folded into the storage of `data`.
Because the `bit_offset` of `padding` is `0x0` and its `DW_AT_byte_size`
is `0x1`, LLDB thinks the field ends at `0x1` (not quite because we
first round the size to a word size, but this is an implementation
detail), erroneously deducing that there's a gap between `flag` and
`padding`.

This patch adds the notion of "effective field end", which accounts for
fields that share storage. It is set to the end of the storage that the
two fields occupy. Then we use this to check for gaps in the unnamed
bitfield creation logic.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications