Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Merged
merged 2 commits into from
Oct 6, 2023
Merged

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

merged 2 commits into from
Oct 6, 2023

Commits on Oct 5, 2023

  1. [lldb][DWARFASTParserClang] Check DW_AT_declaration to determine stat… 

    …ic data members

**Background**

Prior to DWARFv4, there was no clear normative text on how to handle
static data members. Non-normative text suggested we 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 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 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 llvm#68135
    @Michael137
    Michael137 committed Oct 5, 2023
    Configuration menu
    Copy the full SHA
    30ef50b View commit details
    Browse the repository at this point in the history

  2. fixup! git clang-format

    @Michael137
    Michael137 committed Oct 5, 2023
    Configuration menu
    Copy the full SHA
    a3135e3 View commit details
    Browse the repository at this point in the history