This appears to be an interworking problem, though perhaps not quite the same one srsa mentioned above. If my conclusion is correct, the EABI builds should NOT be used until it is resolved, except maybe for digic6.
I narrowed the benchmark failure down to a call to vid_get_viewport_height()
On a540, this function calls _GetVRAMVPixelsSize(), but only if in REC mode.
In the EABI build, the disassembly looks like this
1) thumb to ARM. Note it does B to the arm function, so the existing thumb LR will be used.
000a7444 <__vid_get_viewport_height_from_thumb>:
a7444: 4778 bx pc
a7446: 46c0 nop ; (mov r8, r8)
a7448: eaffb4eb b 947fc <vid_get_viewport_height>
2) vid_get_viewport_height just calls vid_get_viewport_height_proper, again with a straight B and no return instruction
000947fc <vid_get_viewport_height>:
947fc: eafffff0 b 947c4 <vid_get_viewport_height_proper>
3)
000947c4 <vid_get_viewport_height_proper>:
947c4: e92d4008 push {r3, lr}
947c8: eb0049ea bl a6f78 <__mode_get_from_arm>
947cc: e2003c03 and r3, r0, #768 ; 0x300
947d0: e3530c02 cmp r3, #512 ; 0x200
947d4: 0a000004 beq 947ec <vid_get_viewport_height_proper+0x28>
947d8: e20000ff and r0, r0, #255 ; 0xff
947dc: e350002c cmp r0, #44 ; 0x2c
947e0: 0a000003 beq 947f4 <vid_get_viewport_height_proper+0x30>
947e4: e8bd4008 pop {r3, lr}
947e8: ea000073 b 949bc <_GetVRAMVPixelsSize>
947ec: e3a000f0 mov r0, #240 ; 0xf0
947f0: e8bd8008 pop {r3, pc}
947f4: e3a00078 mov r0, #120 ; 0x78
947f8: e8bd8008 pop {r3, pc}
Note the B to _GetVRAMVPixelsSize, after restoring the original LR. So, Canon firmware code gets a thumb LR, but only in rec mode. The compiler appears to assume that any function it calls will return in a thumb-safe manner, which is presumably valid for the code it generates, but is not for the firmware code.
This is less likely to be a problem on DryOS cameras, because they generally use BX or another thumb safe return. The VxWorks cameras frequently use MOV PC, LR (as _GetVRAMVPixelsSize does on A540)
I assume the reason this isn't more of a problem is that there is only risk of it occurring when the compiler optimizes a function call like this.
The corresponding code in the arm-elf build is
00094758 <vid_get_viewport_height_proper>:
94758: e52de004 push {lr} ; (str lr, [sp, #-4]!)
9475c: eb004f39 bl a8448 <__mode_get_from_arm>
94760: e2003c03 and r3, r0, #768 ; 0x300
94764: e3530c02 cmp r3, #512 ; 0x200
94768: 03a000f0 moveq r0, #240 ; 0xf0
9476c: 0a000003 beq 94780 <vid_get_viewport_height_proper+0x28>
94770: e20000ff and r0, r0, #255 ; 0xff
94774: e350002c cmp r0, #44 ; 0x2c
94778: 03a00078 moveq r0, #120 ; 0x78
9477c: 1b000073 blne 94950 <_GetVRAMVPixelsSize>
94780: e49de004 pop {lr} ; (ldr lr, [sp], #4)
94784: e12fff1e bx lr
Which does a BL _GetVRAMVPixelsSize and so will end up using it's own BX LR.
So the question is, is there a way to inform the compiler that firmware stubs are NOT thumb safe?
edit:
I should add that I'm not sure if the elf compiler is actually guarantied to do the right thing, or it's just less aggressive about this kind of optimization.
edit:
PTP live view also suffers the crash, as expected.
An alternate approach might be to make the stubs generate a thumb safe return, but I haven't come up with an efficient way to do it.
