bogo / arm64-to-sim Goto Github PK

In your blog post, you show the output from vtool -show, then shortly after that have a sample command line to modify the library. As far as I can tell, the two command lines are mutually exclusive, since the -show output indicates that the library uses SDK 14.0 while the command line forces it to SDK 13.0. At least with my library (which uses SDK 16.2 with min SDK 13.0), doing that results in a runtime crash (in a C++ destructor in the library). Using 7 13.0 16.2 instead of 7 13.0 13.0 fixes the problem.

Hi @bogo,
I've been playing with the tool as your article looked quite interesting (thanks for it btw 👏)

I've been trying to replicate all the knowledge with a Google framework (GoogleInteractiveMediaAds) that has not shown any news to be integrated as xcframework.
But with no luck yet, I'm stuck with this error:

ld: malformed trie, node past end file '/Users/kikeenrique/Library/Developer/Xcode/DerivedData/Example-hciwziixsbelgaenhtlqornxbvjz/Build/Products/Debug-iphonesimulator/GoogleInteractiveMediaAds.framework/GoogleInteractiveMediaAds'

I've managed to slice it and join it with lipo thin and lipo create.
But there is something wrong with the arm64 version for simulator.
In this framework there are more load commands than in your Spotify example and I still a bit lost of what I would need to do with each of them.
Would be so kind to give some hints or help?

I've already done some modifications on my fork
And here is the otool -fahl dissection for the original arm64 arm64-debug-googleima.txt
Here is a link to the download section for the framework, I've been using latest version 3.13.0:

Regards

Hi, since Xcode 13.3 I cannot patch this library:

lipo -detailed_info libGoogleAnalyticsServices.a
Fat header in: libGoogleAnalyticsServices.a
fat_magic 0xcafebabe
nfat_arch 5
architecture armv7
    cputype CPU_TYPE_ARM
    cpusubtype CPU_SUBTYPE_ARM_V7
    capabilities 0x0
    offset 108
    size 6872432
    align 2^2 (4)
architecture armv7s
    cputype CPU_TYPE_ARM
    cpusubtype CPU_SUBTYPE_ARM_V7S
    capabilities 0x0
    offset 6872540
    size 6879928
    align 2^2 (4)
architecture i386
    cputype CPU_TYPE_I386
    cpusubtype CPU_SUBTYPE_I386_ALL
    capabilities 0x0
    offset 13752468
    size 7031728
    align 2^2 (4)
architecture x86_64
    cputype CPU_TYPE_X86_64
    cpusubtype CPU_SUBTYPE_X86_64_ALL
    capabilities 0x0
    offset 20784200
    size 7180160
    align 2^3 (8)
architecture arm64
    cputype CPU_TYPE_ARM64
    cpusubtype CPU_SUBTYPE_ARM64_ALL
    capabilities 0x0
    offset 27964360
    size 7499168
    align 2^3 (8)

Script is failing due this fatal error:

Arm64ToSimLib/Transmogrifier.swift:49: Fatal error: The file is not a correct arm64 binary. Try thinning (via lipo) or unarchiving (via ar) first.

Using 13.2.1 and arm64-to-sim old version previous to #9 patch worked before. Any clues on how to solve this issue?

I've tried thinning first, but same error result:

lipo -detailed_info libGoogleAnalyticsServices.a.arm64                                  
input file libGoogleAnalyticsServices.a.arm64 is not a fat file
Non-fat file: libGoogleAnalyticsServices.a.arm64 is architecture: arm64

Thanks!

Hi,
I am currently using ur tools to modify binary framework Yandex maps mobile...
Link to framework is taken from here...
Every time am getting zerofill error...

ld: in /Users/c-villain/Library/Developer/Xcode/DerivedData/Utkonos-flitswrpfdrvoncmykfarjwnxqce/Build/Products/Debug-iphonesimulator/YandexMapsMobile.framework/YandexMapsMobile(YMKSearchMasstransit2xObjectMetadata_Binding.mm.o), section __DATA/__bss has type zero-fill but non-zero file offset file '/Users/c-villain/Library/Developer/Xcode/DerivedData/Utkonos-flitswrpfdrvoncmykfarjwnxqce/Build/Products/Debug-iphonesimulator/YandexMapsMobile.framework/YandexMapsMobile' for architecture arm64

build on Xcode 13.3.1

any ideas what's going wrong?...

Hi,

First of all, thank you for this script and for the explanation at the blog!
I do not understand why Apple doesn't let you link device arm64 binaries for simulador arm64 version :(

Well, my problem here is that I'm getting this error below:

Arm64ToSimLib/Transmogrifier.swift:49: Fatal error: The file is not a correct arm64 binary. Try thinning (via lipo) or unarchiving (via ar) first.

I was using a static library that is a fat binary containing armv7, armv7s, i386, x86_64 and arm64 architectures, let's call it "library.a".
lipo -info library.a Architectures in the fat file: library.a are: armv7 armv7s i386 x86_64 arm64

As the error above indicates, I tried to extract from this library only the arm64 slice. I tried it with lipo -extract and also with lipo -thin. Both cases generated me a new library with only arm64 architecture. But it still shows me the same error.
I also tried unarchiving the static library object and generating a new library with only arm64 using ar command as follows but it didn't work either:

lipo -extract arm64 library.a -o newLibrary.a

lipo library.a -thin arm64 -output newLibrary.a

ar -xv library.a; ar -rc newLibrary.a *.o

I edited de code for arm64-to-sim binary to print the mach_header_64 properties, the result is the following:
header: mach_header_64(magic: [1918975009](tel:1918975009), cputype: 171862115, cpusubtype: 841953571, filetype: 538976304, ncmds: 538976288, sizeofcmds: 538976288, flags: 926430769, reserved: 892941365)

I was not able to match this values with any static value from Swift MachO library like CPU_TYPE_ARM64 that is expected in this script.

Am I missing something here? Should I be using a different kind of binary files for this script?

Again, thank you so much for your help. This behavior should be de default for Apple stuff, I’m tired to see answers like remove arch arm64 for simulador or to use Rosetta 2.

Hi,

I am currently using your excellent results to make my app for simulator compatible.
To make this more useful, I am developing an extension of the provided CLI tool, such as batching, add definition files, etc. If possible, I would like to refer to this repository directly as a SwiftPM dependency and use the implementation as a library.

I have two wishes for this.

1. Add a semantic versioning tag to the repository to make it easier to track releases
2. Change error handling using Throw, Error protocol

The proposal for 1. can make this project even more attractive as a library, which is very valuable.

The proposal for 2. is an additional attractive element in making it a library.
The part that currently issues fatalError should be changed to throw using the Error protocol.
In the tool I am currently developing, the fatalError part has been rewritten, so the implementation is different and not good.
I am considering submitting a pull request for this.

Your results have been very helpful, thank you.

Noticed there's a good amount of missing symbols after converting a few arm64 device binaries over and attempting to use them on the M1s - some examples coming from opencv:

  "cv::g_8x32fTab", referenced from:
      _cvRawDataToScalar in libopencv_arm64.a(array.o)
      cv::hal::cpu_baseline::mul8u(unsigned char const*, unsigned long, unsigned char const*, unsigned long, unsigned char*, unsigned long, int, int, double const*) in libopencv_arm64.a(arithm.dispatch.o)
      cv::hal::cpu_baseline::div8u(unsigned char const*, unsigned long, unsigned char const*, unsigned long, unsigned char*, unsigned long, int, int, double const*) in libopencv_arm64.a(arithm.dispatch.o)
      cv::hal::cpu_baseline::addWeighted8u(unsigned char const*, unsigned long, unsigned char const*, unsigned long, unsigned char*, unsigned long, int, int, double const*) in libopencv_arm64.a(arithm.dispatch.o)
      cv::hal::cpu_baseline::recip8u(unsigned char const*, unsigned long, unsigned char*, unsigned long, int, int, double const*) in libopencv_arm64.a(arithm.dispatch.o)
  "cv::g_Saturate8u", referenced from:
      void cv::reduceR_<unsigned char, unsigned char, cv::OpMax<unsigned char> >(cv::Mat const&, cv::Mat&) in libopencv_arm64.a(matrix_operations.o)
      void cv::reduceR_<unsigned char, unsigned char, cv::OpMin<unsigned char> >(cv::Mat const&, cv::Mat&) in libopencv_arm64.a(matrix_operations.o)
      void cv::reduceC_<unsigned char, unsigned char, cv::OpMax<unsigned char> >(cv::Mat const&, cv::Mat&) in libopencv_arm64.a(matrix_operations.o)
      void cv::reduceC_<unsigned char, unsigned char, cv::OpMin<unsigned char> >(cv::Mat const&, cv::Mat&) in libopencv_arm64.a(matrix_operations.o)
      cv::hal::cpu_baseline::add8u(unsigned char const*, unsigned long, unsigned char const*, unsigned long, unsigned char*, unsigned long, int, int) in libopencv_arm64.a(arithm.dispatch.o)
      cv::hal::cpu_baseline::sub8u(unsigned char const*, unsigned long, unsigned char const*, unsigned long, unsigned char*, unsigned long, int, int) in libopencv_arm64.a(arithm.dispatch.o)
      cv::hal::cpu_baseline::min8u(unsigned char const*, unsigned long, unsigned char const*, unsigned long, unsigned char*, unsigned long, int, int) in libopencv_arm64.a(arithm.dispatch.o)
      ...

Hi

I have tried to follow your impressive blog post to make this arm64 simulator hack work on Googles "AFSNative" framework
(https://developers.google.com/custom-search-ads/ios/afsnative)

I was hoping you might be able to point me in the right direction of where I've failed along the way?

I did the file command and saw the 4 architectures are all there.

The lipo to get the arm64 and extracting that also went just fine.

Now, with the folder full of .o files, I went on doing the following (but to be honest I'm not completely sure if that is in fact the next step).
for file in *.o; do arm64-to-sim $file; done;

I didn't see any errors while doing this, so I went on with this
ar crv ../AFSNative.arm64-reworked *.o

But that part did not go so well. I get this kind of error
object: ../AFSNative.arm64-reworked(aligned_new_bca0ac320467a2457b3e306bfed17856.o) malformed object (section contents at offset 640 with a size of 312, overlaps Mach-O headers at offset 0 with a size of 648)

I did notice your section that says

The process requires performing extensive checks to confirm each object is a valid executable, and, thankfully, yields detailed errors. If we made any mistakes or omissions in our offset reconstructions, ar will tell us which section is faulty and what is it overlapping with. From here, we just need to keep hammering on the edits in our code.

But I'm not really sure what parts to look into changing to fix these errors (or if the errors appear, because I didn't do the initial steps correct 🤷 ).

Any ideas/hints to move on with this would be much appreciated.