Skip to content

Commit

Permalink
Downgrade all binaries in GPUSupport.framework
Browse files Browse the repository at this point in the history
  • Loading branch information
@khronokernel
khronokernel committed Mar 24, 2023
1 parent 1790bbc commit b95da2e
Show file tree
Hide file tree
Showing 4 changed files with 0 additions and 0 deletions.
Binary file added .../PrivateFrameworks/GPUCompiler.framework/Versions/31001/Libraries/libComposeFilters.dylib
View file
Binary file not shown.
Binary file added ...rivateFrameworks/GPUCompiler.framework/Versions/31001/Libraries/libllvm-flatbuffers.dylib
View file
Binary file not shown.
Binary file added ...brary/PrivateFrameworks/GPUCompiler.framework/Versions/31001/Libraries/libllvm-lmdb.dylib
View file
Binary file not shown.
Binary file added ...PrivateFrameworks/GPUCompiler.framework/Versions/31001/Libraries/libmetal_timestamp.dylib
View file
Binary file not shown.

15 comments on commit b95da2e

@cgudrian
Copy link

@cgudrian cgudrian commented on b95da2e Sep 5, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These files have the MH_DYLIB_IN_CACHE Mach-O header flag set. This leads to crashes when debugging with LLDB, because the segment address gets sanitized leading to corrupted data. How come this flag is set?

@ASentientBot
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you so much for catching this! I have fixed it in dsce v7, so lldb should finally work on systems with legacy Metal GPUs once OCLP is updated.

I completely misunderstood the crash report and would've never figured this out, so your comment is really appreciated!! (Credited you on dsce.) Thanks again.

@cgudrian
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're welcome! I'm glad that I could give something back!

@cgudrian
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've tried to patch the system myself by mounting the root volume, removing the MH_DYLIB_IN_CACHE from the header, signing the new libraries with my developer identity (I've disable library checking so I'm not sure that was at all necessary) and creating a new blessed snapshot to boot from.
However the boot process gets stuck halfway through. Any idea what I might be missing?

@ASentientBot
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure. You'd have to check /Library/Logs/DiagnosticReports or ssh in and run log stream -debug -info to get an idea what's crashing. I don't see anything obviously wrong in what you've said.

I've also made a branch on PatcherSupportPkg last night, so you could try those binaries if you want. It will get merged once we do some more testing and when OCLP devs have time.

@cgudrian
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll see what I can find out. Thanks!

@cgudrian
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've just replaced libGPUCompilerUtils.dylib from your dev branch and the system won't boot anymore. Here's a screenshot from the last kernel messages:
IMG_3441
I don't see anything obviously wrong, apart from the SD card reader powering off at the very end maybe.

@khronokernel
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Binaries in PatcherSupportPkg's release are signed with our certificates to pass AMFI checks using AMFIPass.kext.
Easiest fix is add amfi=0x80 to your boot-args

@cgudrian
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Adding the boot option did the trick. Debugging SwiftUI apps now works with an unpatched LLDB. What a ride!

@ASentientBot
Copy link
Collaborator

@ASentientBot ASentientBot commented on b95da2e Sep 6, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you Mykola, I entirely forgot about AMFIPass since I always use amfi=128 on my systems🤦🏻‍♀️

And thank you for your patience @cgudrian

@cgudrian
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't worry, @ASentientBot. Actually I've enjoyed the past couple of days. :)

@cgudrian
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can confirm that debugging SwiftUI macOS apps now works with Xcode 14.3.1. I may be brave enough to upgrade to Xcode 15 myself tonight, though it's more likely I'll leave that endeavor to others.

I haven't yet tried debugging in the Simulator. That's the part where my MacBook starts to look old (which it is).

@cgudrian
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It still works with Xcode 15.

@itsj3rm
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ASentientBot sorry for pinging you, seems like the root cause of this issue has been found, but I haven't seen any changes in this repo or the main OCLP repo. It'd be great if you could create a PR with the new binaries in this repo, or maybe just a comment on the OCLP discussion.

Feel free to ignore this if the OCLP team's already aware of this fix 😅, I just want to make sure that the fix won't get unnoticed.

@itsj3rm
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@khronokernel Just realized that you made this commit and not @ASentientBot, it'd be great if you could patch the binaries and fix the lldb issue. If you're busy and working on something else it's fine too, I just hope this fix will eventually make it to a future release.

Please sign in to comment.