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 ...
|