> -----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 <pe...@chocky.org> > @ Modified by Caolan McNamara <caol...@redhat.com> > .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 <pe...@chocky.org> > @ Modified by Caolan McNamara <caol...@redhat.com> > .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 <pe...@chocky.org> > @ Modified by Caolan McNamara <caol...@redhat.com> > .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. -- FFE for lucid - gdb-7.1 (or gdb-7.0.90.2010xxyy) https://bugs.launchpad.net/bugs/535179 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
