Skip to content

[lldb] Assortment of cherry-picks from upstream LLVM #10866

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

Merged
merged 5 commits into from
Jun 20, 2025

Conversation

Michael137
Copy link

Michael137 and others added 5 commits June 18, 2025 11:01
Currently when jitting expressions, LLDB scans the IR instructions of
the `$__lldb_expr` and will insert a call to a utility function for each
load/store instruction. The purpose of the utility funciton is to
dereference the load/store operand. If that operand was an invalid
pointer the utility function would trap and LLDB asks the IR checker
whether it was responsible for the trap, in which case it prints out an
error message saying the expression dereferenced an invalid pointer.

This is a lot of setup for not much gain. In fact, creating/running this
utility expression shows up as ~2% of the expression evaluation time
(though we cache them for subsequent expressions). And the error message
we get out of it is arguably less useful than if we hadn't instrumented
the IR. It was also untested.

Before:
```
(lldb) expr int a = *returns_invalid_ptr()

error: Execution was interrupted, reason: Attempted to dereference an invalid pointer..
The process has been returned to the state before expression evaluation.
```

After:
```
(lldb) expr int a = *returns_invalid_ptr()

error: Expression execution was interrupted: EXC_BAD_ACCESS (code=1, address=0x5).
The process has been returned to the state before expression evaluation.
```

This patch removes this IR checker.

(cherry picked from commit 0a7b0c8)
…argets/frames (llvm#144503)

There's no need to create this utility function (and run it) for
targets/frames that aren't Objective-C/Objective-C++.

(cherry picked from commit 4ced29b)
…le::value_type (llvm#144517)

llvm#143501 changes usage of
`__hash_value_type` in libcxx to an empty tag type. This type will no
longer have a definition in DWARF. Currently the LLDB unordered_map
formatter deduces the map's `element_type` by looking at the `__cc_`
member of `__hash_value_type`. But that will no longer work because we
only have its forward declaration. Since what we're really after is the
type that `__hash_value_type` is wrapping, we can just look at the
`__hash_table::value_type` typedef. With
llvm#143501 that will now point to
the `std::pair` element type (which used to be what we got from
`__cc_`).

TBD: need to double-check this works for older layouts. Quick glance at
the code makes me suspicious of cases like `unordered_map<std::pair<int,
int>, int>`

(cherry picked from commit 382e3fd)
…ng changes

Cherry-picked the LLDB parts from:
```
commit c7df106
Author: Peng Liu <[email protected]>
Date:   Wed Nov 13 05:08:08 2024 -0500

    Unify naming of internal pointer members in std::vector and
std::__split_buffer (llvm#115517)
```

Addresses llvm#144555
…127071)

It's slower and it can fail in contexts where expression evaluation
doesn't work.

(cherry picked from commit 0949330)
@Michael137 Michael137 requested a review from adrian-prantl June 18, 2025 10:05
@Michael137 Michael137 requested a review from a team as a code owner June 18, 2025 10:05
@Michael137
Copy link
Author

@swift-ci test

@adrian-prantl
Copy link

Not entirely sure if that test failure is related.

@adrian-prantl
Copy link

@swift-ci test macOS

@adrian-prantl
Copy link

@adrian-prantl adrian-prantl merged commit 85f1a67 into swift/release/6.2 Jun 20, 2025
3 checks passed
@adrian-prantl adrian-prantl deleted the lldb/ir-checker-changes-to-6.2 branch June 20, 2025 15:47
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.

3 participants