Hanabi Build for Xcode 15.2 missing?

[malhaar]

hey i cant find hanabi build for xcode 15 .. can you please reupload?

[61bcdefg]

Swift was fully broken on Hanabi for xcode15, so I didn't upload it

[malhaar]

i tested old build on latest xcode, just did not inject in swift-frontend and its working fine on objc builds. also any plans for fixing swift-fontend?

[61bcdefg]

Fixing it won't be easy, I'm not going to do

[malhaar]

alright ..

[Naville]

I don't understand the love with injection-based solutions. Back in the older days building Swift was a giant p in the a. It's way much simpler now

[malhaar]

well i can talk for myself not others .. it makes easy to use with xcode and lots still use xcode. Most of people dont know manual setups of compilers .. if i get some tutorial to use it without xcode i will be more than happy to say bye bye to xcode ... tired of it actually ..

[Naville]

Unless you require building for aarch64e (which has other workarounds), using a standalone toolchain works equally good

[malhaar]

@Naville can you please link me to any tutorial for beginners?

[Naville]

Right in the README

[61bcdefg]

Unless you require building for aarch64e (which has other workarounds), using a standalone toolchain works equally good

Actually the workaround for arm64e is unable to work properly like hanabi, if the source code contain objc class, the springboard will crash.

Apple doesn't seem to be pushing the latest arm64e abi implementation into their llvm fork

[Naville]

Unless you require building for aarch64e (which has other workarounds), using a standalone toolchain works equally good

Actually the workaround for arm64e is unable to work properly like hanabi, if the source code contain objc class, the springboard will crash.

Apple doesn't seem to be pushing the latest arm64e abi implementation into their llvm fork

There was a script released by theos developers that patchs the arch tag in MachO to pretend to be the new arm64e abi. Which is stupid, indeed, but works reasonably well in practice

[malhaar]

yeah.. that could work.. @61bcdefg what do you think?

[61bcdefg]

I missed something. For some unknown reason, even though I used apple's fork of llvm, the mach-o was still marked 0x80000002, which led oldabi to think it didn't need to be patched. Also, if I modify the section name, oldabi will not work properly because it assumes that all hikari strings are in the section named __data

[61bcdefg]

Other than that, I've heard it doesn't seem to work with swift (unverified).

[61bcdefg]

A unfortunate news: On Xcode 15.3, clang is also fully broken if hanabi is used, and seems impossible to fix(crash at the backend)

[malhaar]

Damn there goes a good project .. !

[Sfvgtg]

抱歉打扰了，看到了关于Hanabi方案该问题的描述，包括之前用的Swift的独立工具链方案，都或多或少遇到一些问题。是否能添加一下容错机制或者改一下流程？针对编译器开发我是小白，请问以下这种思路是否有可行性？ 做一个统筹的流程控制器作为入口，用来协调切换系统clang跟自己编译的混淆工具，产生IR以及后续的IR到后端的过程都交由系统clang来做，自己的混淆工具只介入到IR的混淆中，当混淆工具报错时切换到系统clang去重新编译一次，

[Naville]

对编译器开发我是小白

?

自己的混淆工具只介入到IR的混淆中，当混淆工具报错时切换到系统clang

现在的兼容性问题就是自己的工具和系统的Clang互相不认识IR了

[61bcdefg]

Now we can use https://github.com/61bcdefg/Hikari-LLVM15/tree/apple-arm64e-upstream-next to build for new arm64e abi, Hanabi will no longer be considered.

https://github.com/61bcdefg/Hikari-LLVM15/issues/106