Comment 67 for bug 417009

Posting output from some investigations yesterday

> -----Original Message-----
> From: Matthew Gretton-Dann

[...]

> After some work with NCommander on IRC yesterday afternoon we
> identified a problem with privateSnippetExecutor being marked
> CANTUNWIND.
>
> Examination of the source shows that this is a piece of
> handwritten assembly which did not have unwind directives
> added to it (source snippet available at
> http://paste.ubuntu.com/391906/. NCommander tried to add
> unwind directives to it (see http://paste.ubuntu.com/391919/
> however this did not work.

[continues below]

[From http://paste.ubuntu.com/391906/:]

> ~/chroot/karmic/src/OOO320_m12/bridges/source/cpp_uno/gcc3_linux_arm$ cat armhelper.s
> @ ARM support code for OpenOffice C++/UNO bridging
> @
> @ Written by Peter Naulls <email address hidden>
> @ Modified by Caolan McNamara <email address hidden>
> .file "armhelper.s"
> .text
> .align 4
> .global privateSnippetExecutor
> .type privateSnippetExecutor, %function
> privateSnippetExecutor:
> stmfd sp!, {r0-r3} @ follow other parameters on stack
> mov r0, ip @ r0 points to functionoffset/vtable
> mov ip, sp @ fix up the ip
> stmfd sp!, {fp,ip,lr,pc} @ 8 x 4 => stack remains 8 aligned
> sub fp, ip, #4 @ set frame pointer
>
> add r1, sp, #16 @ r1 points to this and params
> bl cpp_vtable_call(PLT)
>
> add sp, sp, #32 @ restore stack
> ldr fp, [sp, #-32] @ restore frame pointer
> ldr pc, [sp, #-24] @ return

> src/OOO320_m12/bridges# cat source/cpp_uno/gcc3_linux_arm/armhelper.s
> @ ARM support code for OpenOffice C++/UNO bridging
> @
> @ Written by Peter Naulls <email address hidden>
> @ Modified by Caolan McNamara <email address hidden>
> .file "armhelper.s"
> .text
> .align 4
> .global privateSnippetExecutor
> .type privateSnippetExecutor, %function
> privateSnippetExecutor:
> .fnstart
> .save {r0, r1, r2, r3}
> stmfd sp!, {r0-r3} @ follow other parameters on stack
> mov r0, ip @ r0 points to functionoffset/vtable
> mov ip, sp @ fix up the ip
>
> .save {fp,ip,lr,pc}
> stmfd sp!, {fp,ip,lr,pc} @ 8 x 4 => stack remains 8 aligned
> sub fp, ip, #4 @ set frame pointer
>
> add r1, sp, #16 @ r1 points to this and params
> bl cpp_vtable_call(PLT)
>
> add sp, sp, #32 @ restore stack
> ldr fp, [sp, #-32] @ restore frame pointer
> ldr pc, [sp, #-24] @ return
> .fnend

[From http://paste.ubuntu.com/391919/:]

> src/OOO320_m12/bridges# cat source/cpp_uno/gcc3_linux_arm/armhelper.s
> @ ARM support code for OpenOffice C++/UNO bridging
> @
> @ Written by Peter Naulls <email address hidden>
> @ Modified by Caolan McNamara <email address hidden>
> .file "armhelper.s"
> .text
> .align 4
> .global privateSnippetExecutor
> .type privateSnippetExecutor, %function
> privateSnippetExecutor:
> .fnstart
> .save {r0, r1, r2, r3}
> stmfd sp!, {r0-r3} @ follow other parameters on stack
> mov r0, ip @ r0 points to functionoffset/vtable
> mov ip, sp @ fix up the ip
>
> .save {fp,ip,lr,pc}
> stmfd sp!, {fp,ip,lr,pc} @ 8 x 4 => stack remains 8 aligned
> sub fp, ip, #4 @ set frame pointer
>
> add r1, sp, #16 @ r1 points to this and params
> bl cpp_vtable_call(PLT)
>
> add sp, sp, #32 @ restore stack
> ldr fp, [sp, #-32] @ restore frame pointer
> ldr pc, [sp, #-24] @ return
> .fnend

[continuation]

> After some thought and examination last night I have come to
> the conclusion that this function is fundamentally broken,
> and needs a complete rewrite. If you look at the source the
> last two instructions load from a negative offset from the SP
> which breaks the ABI (and if I signal occurred would cause
> the stack to get corrupted). Ramana and I also can't work
> out what ip should contain on entry to the function (and why
> it is expected to contain a value at all). In its current
> state I don't think we can write an unwinder for this
> function without writing personality routines by hand.
>
> Someone (in OpenOffice land) needs to examine this function,
> work out what is going on and make it conform to the ABI, and
> add an unwinder. This is not a tools issue.
>
> Unfortunately this is only step one, once this function is
> sorted I doubt the bug will be fixed. The other immediate
> issue to be investigated is to find out where the .eh_frame
> sections present in the library are coming from. These
> should not be present on ARM and may be causing an issue.