Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3
# 096c530a 16-Feb-2024 Jonas Devlieghere <jonas@devlieghere.com>

[lldb] Fix Python test formatting (NFC)


Revision tags: llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init
# dcbf1e4e 13-Dec-2023 Greg Clayton <gclayton@fb.com>

[lldb] Fix buildbots after PR 74786 (#75272)

Fix unexpected pass after
https://github.com/llvm/llvm-project/pull/74786.


Revision tags: llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3
# d579a1a2 06-Oct-2023 Michael Buch <michaelbuch12@gmail.com>

[lldb[test] TestCppUnionStaticMembers.py: XFAIL assertions on windows (#68408)

Split out the assertions that fail on Windows in preparation to
XFAILing them.

Drive-by change:
* Add a missing `

[lldb[test] TestCppUnionStaticMembers.py: XFAIL assertions on windows (#68408)

Split out the assertions that fail on Windows in preparation to
XFAILing them.

Drive-by change:
* Add a missing `self.build()` call in `test_union_in_anon_namespace`
* Fix formatting
* Add expectedFailureWindows decorator

show more ...


# f74aaca6 06-Oct-2023 Michael Buch <michaelbuch12@gmail.com>

[lldb][DWARFASTParserClang] Check DW_AT_declaration to determine static data members (#68300)

**Background**

Prior to DWARFv4, there was no clear normative text on how to handle
static data memb

[lldb][DWARFASTParserClang] Check DW_AT_declaration to determine static data members (#68300)

**Background**

Prior to DWARFv4, there was no clear normative text on how to handle
static data members. Non-normative text suggested that compilers should
use `DW_AT_external` to mark static data members of structrues/unions.
Clang does this consistently. However, GCC doesn't, e.g., when the
structure/union is in an anonymous namespace (which is C++ standard
conformant). Additionally, GCC never emits `DW_AT_data_member_location`s
for union members (regardless of storage linkage and storage duration).

Since DWARFv5 (issue 161118.1), static data members get emitted as
`DW_TAG_variable`.

LLDB used to differentiate between static and non-static members by
checking the `DW_AT_external` flag and the absence of
`DW_AT_data_member_location`. With
[D18008](https://reviews.llvm.org/D18008) LLDB started to pretend that
union members always have a `0` `DW_AT_data_member_location` by default
(because GCC never emits these locations).

In [D124409](https://reviews.llvm.org/D124409) LLDB stopped checking the
`DW_AT_external` flag to account for the case where GCC doesn't emit the
flag for types in anonymous namespaces; instead we only check for
presence of `DW_AT_data_member_location`s.

The combination of these changes then meant that LLDB would never
correctly detect that a union has static data members.

**Solution**

Instead of unconditionally initializing the `member_byte_offset` to `0`
specifically for union members, this patch proposes to check for both
the absence of `DW_AT_data_member_location` and `DW_AT_declaration`,
which consistently gets emitted for static data members on GCC and
Clang.

We initialize the `member_byte_offset` to `0` anyway if we determine it
wasn't a static. So removing the special case for unions makes this code
simpler to reason about.

Long-term, we should just use DWARFv5's new representation for static
data members.

Fixes #68135

show more ...