Skip to content

[Cherry-pick] Upstream patches related to DWARF5 and debug_names #8088

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.

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

Conversation

felipepiovezan
Copy link

There are more patches to be cherry-picked, but these are the easiest and all but one are NFC.

ObjectiveC has its own extra accelerator table entries that are helpful for the
debugger. This patch relaxes the DWARFVerifier so that it accepts those in DWARF
5's debug_names.

Differential Revision: https://reviews.llvm.org/D159471

(cherry picked from commit ab0eb59)
The method DWARFDebugInfoEntry::Extract needs to skip over all the data
in the debug_info / debug_types section for each DIE. It had the logic
to do so hardcoded inside a loop, when it already exists in a neatly
isolated function.

(cherry picked from commit ea9e116)
The existing code was taking three substrings from a regex match and converting
to std::strings prior to using them. This may have been done to address
null-termination concerns, but this is not the case:

1. `name` was being used to call `c_str()` and then implicitly converted back to
a `StringRef` on the call to `ToAddress`. While the path `const char *` ->
`StringRef` requires null-termination, we can simply use the original StringRef.
2. `str_offset` was being converted back to a StringRef in order to call a
member method. Member methods can't handle non-null termination.
3. `sign` simply had it's 0-th element accessed.

(cherry picked from commit 7a86cc6)
This will enable us to prove that there is unreachable code in this function in
a subsequent commit.

(cherry picked from commit 3e98a28)
With the combination of an early return and removing an else-after-return, it
becomes evident that there is unreachable code in the function being changed.

(cherry picked from commit d24d7ed)
…Context (llvm#74523)

The function FindDefinitionTypeForDWARFDeclContext loops over all DIEs
corresponding to types with a certain name and compares the context of
each found DIE with the context of a target DIE. However, the target DIE
never changes throughout this search, and yet we recompute its
DeclContext on every iteration of the search. This is wasteful because
the method is not exactly free (see
DWARFDebugInfoEntry::GetDWARFDeclContextStatic).

(cherry picked from commit 9982f8e)
…lvm#74773)

There was duplicated (and complex) code querying whether tags were
type-like tags (i.e. class or struct); this has been factored out into a
helper function.

There was also a comment about not comparing identical DIEs without ever
performing that check; this comment has been removed. It was likely a
result of copy paste from another function in this same file which
actually does that check.

(cherry picked from commit 162248c)
This commit factors out the logic building each component of a qualified
name into its own function so that it may be reused by a future commit,
while also simplifying the logic of assembling these pieces together by
using llvm::interleave.

(cherry picked from commit 06d6af7)
@felipepiovezan
Copy link
Author

@swift-ci test

@felipepiovezan felipepiovezan merged commit 539ec56 into swiftlang:stable/20230725 Jan 31, 2024
@felipepiovezan felipepiovezan deleted the felipe/cherry-picks-debugnames1 branch January 31, 2024 23:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants