This is an archive of the discontinued LLVM Phabricator instance.

Simplify logic to identify dyld_sim in Simulator debugging on macos
ClosedPublic

Authored by jasonmolenda on Dec 2 2021, 2:45 PM.

Details

Summary

The DynamicLoader plugin for macOS needs to identify which binary is the dynamic loader (dyld, aka ld.so) so it can set a breakpoint to be notified about newly added binaries. When debugging a simulator process (iOS process running on a mac, etc), there is both a "dyld" and a "dyld_sim" binary in the process, which both have the same filetype of dynamic loader, but we need to ignore dyld_sim.

The DynamicLoader previously was implementing this by checking if the inferior system is Intel, and if so, if the possibly-dyld binary was actually an iOS/watchOS/tvOS/etc binary. If so, then this is dyld_sim, and we would skip it.

This has the obvious shortcoming on an Apple Silicon system; now we've got an arm64 system running a possibly-dyld with OS type iOS. The inferior system may be iOS.

I took advantage of the fact that we track the simulator in the triple as the Environment. If the environment is simulator, then we only register the possibly-dyld if its OS is macOS.

I also removed an old bit of code to handle old (before 2016) debugserver responses. This code block is only relevant on macOS native systems, so we don't need to worry about debugging an old iOS etc device that might be older than this, running an old debugserver.

Diff Detail

Event Timeline

jasonmolenda created this revision.Dec 2 2021, 2:45 PM
jasonmolenda requested review of this revision.Dec 2 2021, 2:45 PM
jingham accepted this revision.Dec 2 2021, 5:40 PM

We will have gotten the full triple from debugserver by the time we get here, so we'll know the Simulator bit, and we get the os_type for dyld_sim from the mach-o header, which has to be right for other (swift) reasons. So this seems like a solid way to determine which dyld we should use.

This revision is now accepted and ready to land.Dec 2 2021, 5:40 PM