Skip to content

Conversation

@bulbazord
Copy link

No description provided.

…vm#167405)

The code for v16 of the shared cache objc class layout was copy/pasted
from the previous versions incorrectly. Namely, the wrong class offset
list was used and the class_infos index was never updated.

rdar://164430695
(cherry picked from commit 4d27413)
…m growth (llvm#167579)

On Apple's platforms, the size of the shared cache grows steadily. As it
grows, so does its list of ObjC classes. LLDB currently accepts an upper
limit to the number of classes when it extracts the class information.
Every few years we will hit the limit and increase the upper limit of
classes.

This approach is fundamentally unsustainable. On top of needing to
manually adjust the number every few years, our current method requires
us to allocate memory in the inferior process. On macOS this is usually
not a problem, but on embedded devices there is usually a limit to how
much memory a process can allocate before they are killed by the OS.

My solution involves running the metadata extraction logic multiple
times. I've added a new parameter to our utility function `start_idx`
that keeps track of where it stopped during the previous run so that it
may pick up again where it stopped.

rdar://91398396
(cherry picked from commit ec4207b)
@bulbazord
Copy link
Author

@swift-ci please test

After my previous change (llvm#167579), the string exceeded 16380
single-byte characters. MSVC did not like this, so I'm splitting it up
into two strings.

(cherry picked from commit 6806349)
@bulbazord
Copy link
Author

@swift-ci please test

@bulbazord bulbazord merged commit 9ba86a0 into swiftlang:stable/21.x Nov 13, 2025
3 checks passed
@bulbazord bulbazord deleted the 21.x-objc-sharedcache-metadata branch November 13, 2025 00:46
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.

1 participant