By default almost all ELF platforms use an ABI called AAPCS (either
hard or soft float). iOS uses an older ABI called APCS. You can't mix
code from these two worlds in any kind of non-trivial case without a
Do you mean translation layer in loader. If so, loader could replace any ELF invocation by stub function invocation, stub will adjust stack and so on, but stub in this case should know invoking function signature, otherwise
arguments on stack could be missed,
Yep, that's pretty much exactly what I had in mind. You'd probably
need at least some assembler component.
I think it's compiler responsibility.
Compilers generally don't take the responsibility for making two ABIs
compatible, with certain exceptions (ironically, the main one I know
of *is* in ARM, where AAPCS and AAPCS-VFP have some accommodations).
I faced here with bugs, due stack alignment, but as I wrote before, I think realignment or removing orr and use add instead could solve it.
Large data types (larger than 4 bytes) are 4-byte aligned.
This is a big one. It means structs will be laid out differently
unless you're careful, but the most difficult aspect is that it
applies to function calls too. Consider:
void func(int x, long long y)
iOS will pass y in registers r1 and r2. ELF code will expect it in
registers r2 and r3. Similar effects happen to arguments that get
passed on the stack.
+ Register R7 is used as a frame pointer
If I truly understood it's for debug purpose only, but disasmly of my CoreFoundation(ELF) shows r7 usage. Frame pointer on my system is r11.
+ Register R9 has special usage
Document says r9 could be used since iOS 3.0, and I found a usage in my CoreFoundation. So I don't think it could be a problem.
Yes, these ones are probably harmless.
There are other issues too, particularly when you get to C++ (name
mangling and exceptions spring to mind). But I expect you've got
enough to worry about for now.
- orr r2, r1, #4
+ add r2, r1, #4
add instead of orr. Unfortunately, I didn't yet put 36 clang into my chroot to build (I'm not using cross compilation).
But if somebody could point me to proper source code or name the patch, I'll be very appreciate.
I wouldn't rely on this. Trunk emits orr again, it's likely just a
random code perturbation and will bite you elsewhere without a real