Be truthful to the compiler about registers clobbered by asm snippet

The asm code loads values into parameter-passing registers r0-r3.
(That is one of the very purposes of the asm snippet.) We need to tell
the compiler that. The compiler does not analyze the asm snippet and
has no idea by itself what it does.

Otherwise the compiler might well put one of the input values to the
asm snippet, like the "pmethod" (the value of the pMethod variable)
into one of those registers, so that when that value then is used in
the asm snippet, *after* r0-r3 have already been modified, it
obviously is totally unrelated to pMethod any more, and the result is
that the code jumps into hyperspace.

Apparently this has worked purely by luck, or thanks to GCC
conservatively avoiding using the r0-r3 parameter-passing registers in
this way. The problem was noticed when using the same code with Clang.

The above analysis tentatively confirmed by Caolán and Jani Monoses,
who wrote the code.

Change-Id: I3018c2e2ccb83e7a71144425fa404ad28bb955d6

1 files changed, 1 insertions, 1 deletions

diff --git a/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx b/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx
index 424adfa8ab91..b8b7d84961a5 100644
--- a/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx
+++ b/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx
@@ -281,7 +281,7 @@ void callVirtualMethod(
         "mov %[r1], r1\n\t"
         : [r0]"=r" (r0), [r1]"=r" (r1)
         : [pmethod]"m" (pMethod), [pgpr]"m" (pGPR), [pfpr]"m" (pFPR)
-        : "r4", "r5");
+        : "r0", "r1", "r2", "r3", "r4", "r5");
 
     MapReturn(r0, r1, pReturnType, (sal_uInt32*)pRegisterReturn);
 }