llvm dev - Apr 2015 - [LLVMdev] question about alignment of structures on the stack (arm 32)

----------------------------------------
> Date: Thu, 23 Apr 2015 07:09:47 -0700
> Subject: Re: [LLVMdev] question about alignment of structures on the stack
(arm 32)
> From: t.p.northover at gmail.com
> To: alexey.perevalov at hotmail.com
> CC: llvmdev at cs.uiuc.edu; lubos at dolezel.info
>
>>> 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 wrote about responsibility, and took in mind: compiler knows function
signature, but runtime/loader doesn't. Now I don't have any other ideas
instead of keeping signatures of problem functions
in loader.

>
>> 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.
Strange, but in that simple case on ELF I got,
    mov r0, #1
    mov r1, #18
    mov r2, #0
    bl  long_long_func
with the same endian as on iOS,
>
>> + 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.
>
Trunk of llvm's source code ) ?
> Tim.

>> 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.
> Strange, but in that simple case on ELF I got,
>     mov r0, #1
>     mov r1, #18
>     mov r2, #0
>     bl  long_long_func
> with the same endian as on iOS,
That almost certainly means you're using the wrong triple on Linux
(and so would have problems calling system library functions with that
signature). Most ARM linux distributions these days use
arm-linux-gnueabihf (or possibly arm-linux-gnueabi, the difference
being where floating-point arguments get passed).

If that's changed in your upgrade to 3.6, it might account for you
seeing "add" instead of "orr" now, too.
>> 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.
>>
> Trunk of llvm's source code ) ?
Yes.

Tim.

----------------------------------------
> Date: Thu, 23 Apr 2015 09:33:58 -0700
> Subject: Re: [LLVMdev] question about alignment of structures on the stack
(arm 32)
> From: t.p.northover at gmail.com
> To: alexey.perevalov at hotmail.com
> CC: llvmdev at cs.uiuc.edu; lubos at dolezel.info
>
>>> 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.
>> Strange, but in that simple case on ELF I got,
>> mov r0, #1
>> mov r1, #18
>> mov r2, #0
>> bl long_long_func
>> with the same endian as on iOS,
>
> That almost certainly means you're using the wrong triple on Linux
> (and so would have problems calling system library functions with that
> signature). Most ARM linux distributions these days use
> arm-linux-gnueabihf (or possibly arm-linux-gnueabi, the difference
> being where floating-point arguments get passed).
>
You totally right.
> If that's changed in your upgrade to 3.6, it might account for you
> seeing "add" instead of "orr" now, too.
>
>>> 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.
>>>
>> Trunk of llvm's source code ) ?
>
> Yes.
>
> Tim.