Skip to content

Cherry-pick the workaround for using older dyld_sim's on newer dyld's #8242

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 3 commits into from
Feb 21, 2024

Conversation

jimingham
Copy link

No description provided.

…imulator dyld's (llvm#78004)

There's a bad interaction between the macOS 14 dyld and the "dyld_sim"
shim that comes from older (iOS 15) simulator downloads that results in
dyld reporting some modules twice in the return from the dyld callback
to list modules. The records were identical, but lldb wasn't happy with
seeing the duplicates...

Since it's not possible to load two different modules at the same
address, this change just picks the first instance of any entries that
have the same load address.

There really isn't a good way to test this patch.

(cherry picked from commit 32dd5b2)
We claim in a couple places that the zeroth element of the module list
for a target is the main executable, but we don't actually enforce that
in the ModuleList class. As we saw, for instance, in

32dd5b2

it's not all that hard to get this to be off. This patch ensures that
the first object file of type Executable added to it is moved to the
front of the ModuleList. I also added a test for this.

In the normal course of operation, where the executable is added first,
this only adds a check for whether the first element in the module list
is an executable. If that's true, we just append as normal.

Note, the code in Target::GetExecutableModule doesn't actually agree
that the zeroth element must be the executable, it instead returns the
first Module of type Executable. But I can't tell whether that was a
change in intention or just working around the bug that we don't always
maintain this ordering. But given we've said this in scripting as well
as internally, I think we shouldn't change our minds about this.
…int (llvm#78377)

Follow-on to a4cd99e - I forgot you
have to add ANY shared library you want to use to extra_images...

(cherry picked from commit 705c5b8)
@jimingham
Copy link
Author

@swift-ci please test

@jimingham jimingham merged commit 23f3e51 into swiftlang:stable/20230725 Feb 21, 2024
@jimingham jimingham deleted the old-sim-for-stable branch February 21, 2024 17:55
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