[LLVMdev] question about alignment of structures on the stack (arm 32)

[Tim Northover]

>> 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
>> translation layer.
>
> 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
solution.

Tim.