[Libreoffice] build or rawbuild dir?
This page describes building in the topmost dir http://www.documentfoundation.org/develop/ whereas the wiki-page example changes to rawbuild before. Which one is recommended? I have been building from topmost dir so far. thanks Jani ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] EasyHack RTL_CONSTASCII_USTRINGPARAM in starmath
Hello, This changes the only occurrence in writer/starmath. The wiki entry does not mention it, but should UNOOUSTRING::createFromAscii (not OUString) be replaced as well? There are two of that in starmath Jani From da30daf2c9cf9d1f19da7b674a8896fc5fa6e453 Mon Sep 17 00:00:00 2001 From: Jani Monoses j...@ubuntu.com Date: Sat, 30 Oct 2010 02:12:24 +0300 Subject: [PATCH 2/2] use RTL_CONSTASCII_USTRINGPARAM --- starmath/source/mathmlexport.cxx |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/starmath/source/mathmlexport.cxx b/starmath/source/mathmlexport.cxx index 97088bb..c5fdd81 100644 --- a/starmath/source/mathmlexport.cxx +++ b/starmath/source/mathmlexport.cxx @@ -621,7 +621,7 @@ sal_uInt32 SmXMLExport::exportDoc(enum XMLTokenEnum eClass) // make use of a default namespace ResetNamespaceMap();// Math doesn't need namespaces from xmloff, since it now uses default namespaces (because that is common with current MathML usage in the web) -_GetNamespaceMap().Add( OUString::createFromAscii(), GetXMLToken(XML_N_MATH), XML_NAMESPACE_MATH ); +_GetNamespaceMap().Add( OUString(RTL_CONSTASCII_USTRINGPARAM()), GetXMLToken(XML_N_MATH), XML_NAMESPACE_MATH ); rList.AddAttribute(GetNamespaceMap().GetAttrNameByKey(XML_NAMESPACE_MATH_IDX), GetNamespaceMap().GetNameByKey( XML_NAMESPACE_MATH_IDX)); -- 1.7.0.4 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] supported compilers?
Is there a list of which compilers are supported and what versions
recommeneded for building LO?
I was thinking of the feasibility of using gcc's __builtin_constant_p in
a macro to differentiate fast and not so fast paths for createFromAscii
cases to keep the code uniform but still get the optimizations, but then
figured that would not work with Visual Studio.
Jani
Ex:
#include stdio.h
#define CONSTACTION(str) printf(%s is const\n, str)
#define VARACTION(str) printf(%s is not known to be const\n, str)
#define ACTION(str) if (__builtin_constant_p(str)) {\
CONSTACTION(str); \
} else {\
VARACTION(str);\
}
int main(int argc, char *argv[]) {
char *s = ss;
ACTION(cc);
ACTION(s);
return 0;
}
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LibreOffice and Java
On 11/03/2010 04:06 PM, Caolán McNamara wrote: On Tue, 2010-11-02 at 14:30 +0100, Cedric Bosdonnat wrote: On Tue, 2010-11-02 at 12:47 +, Michael Meeks wrote: Quite; cf. such uncertainty - it probably makes considerable sense to look into a migration strategy from Java to (insert anything else). Some candidates might be python for the more scripty pieces (though I hate non-typed languages), and/or native C++. What about the existing Java extensions? Quite a lot of people are using Java to either writer extensions or use UNO Java bridge from an external application. Its not, at least that's my understanding, about removing the java-uno bridge, or removing the *ability* to support Java. Its the thought to consider not defaulting to *require* Java for the built-in bits, which probably mostly boils down to defaulting base to a different backend for file based databases and a redo an occasional wizard here and there. Out of the over 3400 java files in the repos, over half seem to be tests (some in directories called test/ others in qa/ - is there a difference?), and over 200 are wizard related, so it seems a lot of UI work to port these if they are all indeed part of the default install. Jani ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] getting LO into debian
On 11/27/2010 05:36 PM, Rene Engelhard wrote: Hi, On Sat, Nov 27, 2010 at 04:22:06PM +0100, Rene Engelhard wrote: On Sat, Nov 27, 2010 at 04:08:37PM +0100, Jonathan Aquilina wrote: hey guys what is being done to get LO into debian so that downstream It already for almost a month. to make that more precise: first upload to Debian on *Oct, 13*. Accepted (because NEW package) etc.: Nov, 8. That was beta2. Beta3 got accepted on Nov, 18. http://packages.qa.debian.org/libr/libreoffice.html http://packages.debian.org/libreoffice ubuntu can get it pulled from the upstream debian repository? Ask them, not me. If they can't do a simple pull in one month, though they are paid for doing it and /me who did already the major work (also at nights!) for it, well.. There may be exceptions but I think Ubuntu pulls from sid not from experimental as a rule. When the package appears in sid it will probably be available in Ubuntu devel version in a short time. Jani ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] getting LO into debian
The OPs mail simply shows Ubuntus attitude and cluelessless, both reasons for why they have to die. http://www.youtube.com/watch?v=zrzMhU_4m-g#t=1m20s ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LibreOffice and Wayland support
On 01/25/2011 11:13 AM, Alexander Thurgood wrote: Le 25/01/11 08:24, Jonathan Aquilina a écrit : Hi Jonathan, Correct me if I am wrong but wont LO be a little screwed since LO only supports X from what I have seen codewise? That was precisely my point : applications have to be rewritten to work with Wayland. At least LibreOffice won't be the only application concerned, which is some consolation !! Applications using more popular toolkits will have an easier transition though, as the porting will mostly be done in those toolkits' code. Jani ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] remove unused declaration - an unlikely fix for armel segfault in regcomp
Hello, this declaration seems to not be used. A similar one exists in the file token.cxx in formula/ where this was copied from according to the comments. This, in combination with some toolchain issue I guess caused regcomp crashing on Ubuntu armel at the install phase. From what I gathered so far the FixedMemPool destructor for the first instance (in formula's token.cxx) was overwritten by the destructor in sc's token.cxx. When running these destructors in regcomp's atexit/fini, the formula one was never called, while the sc one was called twice resulting in the segfault. This only occured if the registry file was not already there, in which case there was no crash but arena tracing printed out bad memory anyway. I don't know if this was the case for other arch's as well and they were just lucky in avoiding the segfault, or it's an armel toolchain issue at play as well. Jani From 7305b53aad89f4c0362e6126edc8f1930eed22f4 Mon Sep 17 00:00:00 2001 From: Jani Monoses jani.mono...@canonical.com Date: Thu, 27 Jan 2011 15:33:06 +0200 Subject: [PATCH] Remove unused declaration --- sc/source/core/tool/token.cxx |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/sc/source/core/tool/token.cxx b/sc/source/core/tool/token.cxx index 3298517..48021b1 100644 --- a/sc/source/core/tool/token.cxx +++ b/sc/source/core/tool/token.cxx @@ -110,9 +110,6 @@ namespace // } // namespace // -// ImpTokenIterator wird je Interpreter angelegt, mehrfache auch durch -// SubCode via FormulaTokenIterator Push/Pop moeglich -IMPL_FIXEDMEMPOOL_NEWDEL( ImpTokenIterator, 32, 16 ) // Align MemPools on 4k boundaries - 64 bytes (4k is a MUST for OS/2) -- 1.7.2.3 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] remove unused declaration - an unlikely fix for armel segfault in regcomp
Hi Michael, thanks for pushing to 3.3 When there's a relase with the patch included, it should close this issue I opened a few days ago https://bugs.freedesktop.org//show_bug.cgi?id=33402 Having said that, it is already fixed in master, so I just merged your patch to libreoffice-3-3 - so it will be in 3.3.1. ah, I did not know this was already fixed in master, I worked on the rc4 release. Great to have you contributing, and looking forward to any other funky ARM pieces you have. Out of interest - did the unit tests execute correctly during the build ? The smoke-tests (if that is what you are referring to) are currently disabled in the Ubuntu package build. I have very little knowledge of LibO and packaging internals, this debugging adventure was 'a vertical' :) Other than that everything up to the install phase executed correctly, and I did not get to test yet what is after installing - a full rebuild takes the better part of the day even if this is among the faster arm machines (pandaboard) Jani ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] remove unused declaration - an unlikely fix for armel segfault in regcomp
On 01/27/2011 05:31 PM, Caolán McNamara wrote:
On Thu, 2011-01-27 at 15:42 +0200, Jani Monoses wrote:
armel
sal/osl/unx/interlck.c probably should have a specific impl for arm btw,
probably a low hanging fruit for someone who knows a little bit of arm
assembly.
What about using GCC atomic builtins like in the attached patch?
If correct (seems so, but I did no test it beyond building it - are
there tests for this in LibO?) it has the advantage of covering more
than ARM, and for ARM letting gcc emit optimal (I hope) code by
taking care of differences between atomic exchange primitives on ARM pre
v6 (SWP) and newer (STREX/LDREX) and memory barrier instructions
(DMB vs MCR ). Debian still builds for armv5 while Ubuntu for armv7
so there would have been at least some ifdefs if assembly were used.
IMHO it is better to stick to portable C/C++ if it does not constitute a
drawback otherwise :)
Jani
From 6570fea4a5851db6dce6f2c9e69133115026ff63 Mon Sep 17 00:00:00 2001
From: Jani Monoses jani.mono...@canonical.com
Date: Thu, 27 Jan 2011 20:02:10 +0200
Subject: [PATCH] Add oslInterlockedCount inc/dec functions using GCC atomic builtins
---
osl/unx/interlck.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/osl/unx/interlck.c b/osl/unx/interlck.c
index f164371..51c1c9e 100644
--- a/osl/unx/interlck.c
+++ b/osl/unx/interlck.c
@@ -135,6 +135,16 @@ oslInterlockedCount SAL_CALL osl_decrementInterlockedCount(oslInterlockedCount*
return nCount;
}
+#elif defined ( GCC )
+oslInterlockedCount SAL_CALL osl_incrementInterlockedCount(oslInterlockedCount* pCount)
+{
+ return __sync_add_and_fetch(pCount, 1);
+}
+
+oslInterlockedCount SAL_CALL osl_decrementInterlockedCount(oslInterlockedCount* pCount)
+{
+ return __sync_sub_and_fetch(pCount, 1);
+}
#else
/* use only if nothing else works, expensive due to single mutex for all reference counts */
--
1.7.2.3
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] remove unused declaration - an unlikely fix for armel segfault in regcomp
On 01/29/2011 03:04 PM, Caolán McNamara wrote: On Thu, 2011-01-27 at 20:13 +0200, Jani Monoses wrote: What about using GCC atomic builtins like in the attached patch? Excellent, the pthread fallback always niggled me. Sorry for not thinking about this earlier, can this be cherry-picked into the 3.3 branch? Jani ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] remove unused declaration - an unlikely fix for armel segfault in regcomp
On 03/09/2011 06:01 PM, Caolán McNamara wrote: On Wed, 2011-03-09 at 10:46 +0200, Jani Monoses wrote: On 01/29/2011 03:04 PM, Caolán McNamara wrote: On Thu, 2011-01-27 at 20:13 +0200, Jani Monoses wrote: What about using GCC atomic builtins like in the attached patch? Excellent, the pthread fallback always niggled me. Sorry for not thinking about this earlier, can this be cherry-picked into the 3.3 branch? This doesn't affect a lot of people in practice, only the Linux non-x86/x86_64 people IIRC, +1 from me if you want to stick it into 3-3. Great. Who can do the actual sticking into 3.3 (I can't) ? This was the master commit: 788072cefdce8cb61d46549a7aede4c754d9fae3 thanks Jani ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] reviewboard: a solution or just creating new problems?
On 04/21/2011 07:17 PM, Bjoern Michaelsen wrote: Hi all, I just want to bring up an idea of which I am not really sure if it is a good one. Currently we have new contributors writing patches to the dev-ML and grant them direct repository access later. Commiting directly on the master might be quite scary at first, so I wondered if something like: http://www.reviewboard.org/ might help the migration. It has a nifty interface (look at their page to get a sales pitch) and all that jazz, but: - it would be another system to setup and maintain - it would require its own logins (or integration in the existing infra) - lots of other things I have not considered yet. So -- I am not sure, if it is a good idea. I just wanted to get this of my chest, so that I wont be sorry later for not speaking up about it. I think using code review helper apps is a great idea, and the lack of their use in any non-trivial FOSS project with many contributors will be in 5 years as perplexing as seeing one now going without the use version control software :) I had used Gerrit a bit and I found it very nice. Easy to deploy (Java) I did not use Reviewboard so I cannot compare. Gerrit was made to work with git specifically and is used by the Android developer ecosystem. There is some work to set up and to maintain, but I think commiters would be happy to be able to just Ack a patch in a web ui and have the commit happen automatically. One drawback is the some of the feedback that now happens inline on the mailing list for all to learn from, would move to the webapp in merge request comments. To a certain degree that would be similar to feedback that happens in bugzilla so maybe not a terrible loss. Very specific code related comments vs higher level discussion on the devel list. I think having such a system set up in demo/trial mode would have a better chance of generating feedback. Jani ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [RFC] npapi-sdk instead of xulrunner
On 09/29/2011 06:01 PM, Tomáš Chvátal wrote: Hi, I was noticed that there is package called npapi-sdk [1] that can be used as firefox/mozilla headers instead of requiring whole beast to build the plugins. Do you think it would be possible to use this in libreoffice, or is it impossible? I don't understand the nsplugin part much, and it was just reported by users at gentoo [2]. There are only 4 C header files that are needed to build a NPAPI plugin. They may as well be shipped inside LibO and not bother with external deps for this - it would mean adding another build/configure test for npapi-sdk along with the ones looked for now. The NPAPI API is stable so an internal copy should be fine. But I think mozilla build-dep was needed anyway for LDAP, I don't know if that dependency is obsolete or not. Jani ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice-commits] .: configure.in
configure.in |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) New commits: commit b3aabdb9a12b550c0c3a537adf4517d5676dec69 Author: Jani Monoses j...@ubuntu.com Date: Fri Feb 3 11:58:25 2012 +0200 Fix typo in configure message diff --git a/configure.in b/configure.in index 6009518..ce50406 100644 --- a/configure.in +++ b/configure.in @@ -4951,7 +4951,7 @@ linux-gnu*) JAVA_TOOLKIT=server ;; *) -AC_MSG_ERROR([No JAVALIB defintion host_cpu $host_cpu for host_os $host_os]) +AC_MSG_ERROR([No JAVALIB definition host_cpu $host_cpu for host_os $host_os]) ;; esac ;; ___ Libreoffice-commits mailing list Libreoffice-commits@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] .: configure.in
configure.in |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) New commits: commit 40991706e4343789015432331d5be93fd7abe373 Author: Jani Monoses j...@ubuntu.com Date: Fri Feb 3 12:09:02 2012 +0200 Fix configure step on various arm linux targets. Use arm* wildcard to match armel|armv7l|arm etc. diff --git a/configure.in b/configure.in index ce50406..d9979e2 100644 --- a/configure.in +++ b/configure.in @@ -2732,7 +2732,7 @@ linux-gnu*) CPUNAME=AXP OUTPATH=unxlngaxp ;; -armel) +arm*) CPU=R CPUNAME=ARM OUTPATH=unxlngr @@ -4872,7 +4872,7 @@ linux-gnu*) JAVA_ARCH=alpha JAVA_TOOLKIT=server ;; -arm) +arm*) JAVA_ARCH=arm JAVA_TOOLKIT=server ;; ___ Libreoffice-commits mailing list Libreoffice-commits@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] .: bridges/source
bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
New commits:
commit 4e679ee2501a0babcdce498732d68428d46481e3
Author: Jani Monoses j...@ubuntu.com
Date: Fri Feb 3 22:11:08 2012 +0200
Simplify code and use proper register names for linux armhf
diff --git a/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx
b/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx
index 9502b87..ac8ca23 100644
--- a/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx
+++ b/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx
@@ -152,11 +152,6 @@ namespace arm
void MapReturn(sal_uInt32 r0, sal_uInt32 r1, typelib_TypeDescriptionReference
* pReturnType, sal_uInt32* pRegisterReturn)
{
-#if !defined(__ARM_EABI__) !defined(__SOFTFP__)
-register float fret asm(f0);
-register double dret asm(f0);
-#endif
-
switch( pReturnType-eTypeClass )
{
case typelib_TypeClass_HYPER:
@@ -176,6 +171,7 @@ void MapReturn(sal_uInt32 r0, sal_uInt32 r1,
typelib_TypeDescriptionReference *
#if !defined(__ARM_PCS_VFP) (defined(__ARM_EABI__) || defined(__SOFTFP__))
pRegisterReturn[0] = r0;
#else
+register float fret asm(s0);
*(float*)pRegisterReturn = fret;
#endif
break;
@@ -184,6 +180,7 @@ void MapReturn(sal_uInt32 r0, sal_uInt32 r1,
typelib_TypeDescriptionReference *
pRegisterReturn[1] = r1;
pRegisterReturn[0] = r0;
#else
+register double dret asm(d0);
*(double*)pRegisterReturn = dret;
#endif
break;
___
Libreoffice-commits mailing list
Libreoffice-commits@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] .: bridges/source
bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx | 49 --
1 file changed, 20 insertions(+), 29 deletions(-)
New commits:
commit a55fa2d0a8f709bd58e2729b66fd8ecc807c0286
Author: Jani Monoses j...@ubuntu.com
Date: Wed Feb 8 21:23:50 2012 +0200
Remove unnecessary variable
diff --git a/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx
b/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx
index ac8ca23..fc8a9e2 100644
--- a/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx
+++ b/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx
@@ -258,16 +258,14 @@ void callVirtualMethod(
}
}
-#define INSERT_INT32( pSV, nr, pGPR, pDS, bOverflow ) \
+#define INSERT_INT32( pSV, nr, pGPR, pDS ) \
if ( nr arm::MAX_GPR_REGS ) \
pGPR[nr++] = *reinterpret_castsal_uInt32 *( pSV ); \
else \
-bOverFlow = true; \
-if (bOverFlow) \
*pDS++ = *reinterpret_castsal_uInt32 *( pSV );
#ifdef __ARM_EABI__
-#define INSERT_INT64( pSV, nr, pGPR, pDS, pStart, bOverflow ) \
+#define INSERT_INT64( pSV, nr, pGPR, pDS, pStart ) \
if ( (nr arm::MAX_GPR_REGS) (nr % 2) ) \
{ \
++nr; \
@@ -278,8 +276,6 @@ void callVirtualMethod(
pGPR[nr++] = *(reinterpret_castsal_uInt32 *( pSV ) + 1); \
} \
else \
-bOverFlow = true; \
-if (bOverFlow) \
{ \
if ( (pDS - pStart) % 2) \
{ \
@@ -289,31 +285,27 @@ void callVirtualMethod(
*pDS++ = reinterpret_castsal_uInt32 *( pSV )[1]; \
}
#else
-#define INSERT_INT64( pSV, nr, pGPR, pDS, pStart, bOverflow ) \
-INSERT_INT32( pSV, nr, pGPR, pDS, bOverflow) \
-INSERT_INT32( ((sal_uInt32*)pSV)+1, nr, pGPR, pDS, bOverflow)
+#define INSERT_INT64( pSV, nr, pGPR, pDS, pStart ) \
+INSERT_INT32( pSV, nr, pGPR, pDS ) \
+INSERT_INT32( ((sal_uInt32*)pSV)+1, nr, pGPR, pDS )
#endif
-#define INSERT_FLOAT( pSV, nr, pFPR, pDS, bOverflow ) \
-INSERT_INT32( pSV, nr, pGPR, pDS, bOverflow)
+#define INSERT_FLOAT( pSV, nr, pFPR, pDS ) \
+INSERT_INT32( pSV, nr, pGPR, pDS )
-#define INSERT_DOUBLE( pSV, nr, pFPR, pDS, pStart, bOverflow ) \
-INSERT_INT64( pSV, nr, pGPR, pDS, pStart, bOverflow )
+#define INSERT_DOUBLE( pSV, nr, pFPR, pDS, pStart ) \
+INSERT_INT64( pSV, nr, pGPR, pDS, pStart )
-#define INSERT_INT16( pSV, nr, pGPR, pDS, bOverflow ) \
+#define INSERT_INT16( pSV, nr, pGPR, pDS ) \
if ( nr arm::MAX_GPR_REGS ) \
pGPR[nr++] = *reinterpret_castsal_uInt16 *( pSV ); \
else \
-bOverFlow = true; \
-if (bOverFlow) \
*pDS++ = *reinterpret_castsal_uInt16 *( pSV );
-#define INSERT_INT8( pSV, nr, pGPR, pDS, bOverflow ) \
+#define INSERT_INT8( pSV, nr, pGPR, pDS ) \
if ( nr arm::MAX_GPR_REGS ) \
pGPR[nr++] = *reinterpret_castsal_uInt8 *( pSV ); \
else \
-bOverFlow = true; \
-if (bOverFlow) \
*pDS++ = *reinterpret_castsal_uInt8 *( pSV );
namespace {
@@ -340,7 +332,6 @@ static void cpp_call(
void * pCppReturn = 0; // if != 0 != pUnoReturn, needs reconversion
-bool bOverFlow = false;
bool bSimpleReturn = true;
if (pReturnTypeDescr)
{
@@ -356,13 +347,13 @@ static void cpp_call(
? __builtin_alloca( pReturnTypeDescr-nSize )
: pUnoReturn); // direct way
-INSERT_INT32( pCppReturn, nGPR, pGPR, pStack, bOverFlow );
+INSERT_INT32( pCppReturn, nGPR, pGPR, pStack );
}
}
// push this
void * pAdjustedThisPtr = reinterpret_cast void ** (pThis-getCppI())
+ aVtableSlot.offset;
-INSERT_INT32( pAdjustedThisPtr, nGPR, pGPR, pStack, bOverFlow );
+INSERT_INT32( pAdjustedThisPtr, nGPR, pGPR, pStack );
// stack space
OSL_ENSURE( sizeof(void *) == sizeof(sal_Int32), ### unexpected size! );
@@ -394,7 +385,7 @@ static void cpp_call(
#if OSL_DEBUG_LEVEL 2
fprintf(stderr, hyper is %lx\n, pCppArgs[nPos]);
#endif
-INSERT_INT64( pCppArgs[nPos], nGPR, pGPR, pStack, pStackStart,
bOverFlow );
+INSERT_INT64( pCppArgs[nPos], nGPR, pGPR, pStack, pStackStart
);
break;
case typelib_TypeClass_LONG:
case typelib_TypeClass_UNSIGNED_LONG:
@@ -402,22 +393,22 @@ static void cpp_call(
#if OSL_DEBUG_LEVEL 2
fprintf(stderr, long is %x\n, pCppArgs[nPos]);
#endif
-INSERT_INT32( pCppArgs[nPos], nGPR, pGPR, pStack, bOverFlow );
+INSERT_INT32( pCppArgs[nPos], nGPR, pGPR, pStack );
break;
case typelib_TypeClass_SHORT:
case typelib_TypeClass_CHAR:
case typelib_TypeClass_UNSIGNED_SHORT:
-INSERT_INT16( pCppArgs[nPos], nGPR, pGPR, pStack, bOverFlow
[Libreoffice-commits] .: bridges/source
bridges/source/cpp_uno/gcc3_linux_arm/armhelper.S | 18 +++
bridges/source/cpp_uno/gcc3_linux_arm/cpp2uno.cxx | 34 ++-
bridges/source/cpp_uno/gcc3_linux_arm/share.hxx |2
bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx | 105 +++---
4 files changed, 142 insertions(+), 17 deletions(-)
New commits:
commit dab11f7fe2a2fa4155e4c4feaa5fc54e57cfbd37
Author: Jani Monoses j...@ubuntu.com
Date: Fri Feb 10 14:50:22 2012 +0200
ARM bridge: VFP ABI (armhf) support
diff --git a/bridges/source/cpp_uno/gcc3_linux_arm/armhelper.S
b/bridges/source/cpp_uno/gcc3_linux_arm/armhelper.S
index d5faf15..27148dc 100644
--- a/bridges/source/cpp_uno/gcc3_linux_arm/armhelper.S
+++ b/bridges/source/cpp_uno/gcc3_linux_arm/armhelper.S
@@ -10,6 +10,17 @@
# define UNWIND @
#endif
+@ If the VFP ABI variant (armhf in Debian/Ubuntu) is used, an additional extra
64 bytes
+@ are taken up on the stack (the equivalent of the 8 double precision VFP
registers)
+
+#ifdef __ARM_PCS_VFP
+# define PAD 80
+# define DISCARDED 84
+#else
+# define PAD 16
+# define DISCARDED 20
+#endif
+
.file armhelper.s
.text
.align 4
@@ -19,9 +30,12 @@ privateSnippetExecutor:
UNWIND .fnstart@ start of unwinder entry
stmfd sp!, {r0-r3} @ follow other parameters on stack
- UNWIND .pad #16 @ throw this data away on exception
mov r0, ip @ r0 points to functionoffset/vtable
mov r1, sp @ r1 points to this and params
+#ifdef __ARM_PCS_VFP
+ vpush {d0-d7} @ floating point parameter on stack
+#endif
+ UNWIND .pad #PAD @ throw this data away on exception
@ (see cppuno.cxx:codeSnippet())
stmfd sp!, {r4,lr} @ save return address
@ (r4 pushed to preserve stack alignment)
@@ -30,7 +44,7 @@ privateSnippetExecutor:
blcpp_vtable_call(PLT)
add sp, sp, #4 @ no need to restore r4 (we didn't touch it)
- ldr pc, [sp], #20@ return, discarding function arguments
+ ldr pc, [sp], #DISCARDED @ return, discarding function arguments
UNWIND .fnend @ end of unwinder entry
diff --git a/bridges/source/cpp_uno/gcc3_linux_arm/cpp2uno.cxx
b/bridges/source/cpp_uno/gcc3_linux_arm/cpp2uno.cxx
index d347aa0..07bdea1 100644
--- a/bridges/source/cpp_uno/gcc3_linux_arm/cpp2uno.cxx
+++ b/bridges/source/cpp_uno/gcc3_linux_arm/cpp2uno.cxx
@@ -69,6 +69,9 @@ namespace
char * pTopStack = (char *)(pCallStack + 0);
char * pCppStack = pTopStack;
+#ifdef __ARM_PCS_VFP
+char * pFloatArgs = (char *)(pCppStack - 64);
+#endif
// return
typelib_TypeDescription * pReturnTypeDescr = 0;
if (pReturnTypeRef)
@@ -125,7 +128,9 @@ namespace
{
case typelib_TypeClass_HYPER:
case typelib_TypeClass_UNSIGNED_HYPER:
+#ifndef __ARM_PCS_VFP
case typelib_TypeClass_DOUBLE:
+#endif
if ((pCppStack - pTopStack) % 8) pCppStack+=sizeof(sal_Int32);
//align to 8
break;
default:
@@ -133,13 +138,31 @@ namespace
}
#endif
-pCppArgs[nPos] = pCppStack;
-pUnoArgs[nPos] = pCppStack;
+// For armhf we get the floating point arguments from a different area of the
stack
+// TODO: deal with functions with more than 8 floating point args that need to
overflow
+// to the stack. Find such an UNO API to try on.
+#ifdef __ARM_PCS_VFP
+if (pParamTypeDescr-eTypeClass == typelib_TypeClass_FLOAT)
+{
+pCppArgs[nPos] = pUnoArgs[nPos] = pFloatArgs;
+pFloatArgs += sizeof(float);
+} else
+if (pParamTypeDescr-eTypeClass == typelib_TypeClass_DOUBLE)
+{
+if ((pFloatArgs - pTopStack) % 8)
pFloatArgs+=sizeof(float); //align to 8
+pCppArgs[nPos] = pUnoArgs[nPos] = pFloatArgs;
+pFloatArgs += sizeof(double);
+} else
+#endif
+pCppArgs[nPos] = pUnoArgs[nPos] = pCppStack;
+
switch (pParamTypeDescr-eTypeClass)
{
case typelib_TypeClass_HYPER:
case typelib_TypeClass_UNSIGNED_HYPER:
+#ifndef __ARM_PCS_VFP
case typelib_TypeClass_DOUBLE:
+#endif
pCppStack += sizeof(sal_Int32); // extra long
break;
default:
@@ -179,6 +202,13 @@ namespace
TYPELIB_DANGER_RELEASE( pParamTypeDescr );
}
}
+#ifdef __ARM_PCS_VFP
+// use the stack for output parameters or non floating point values
+if (rParam.bOut
[Libreoffice-commits] .: bridges/source
bridges/source/cpp_uno/gcc3_linux_arm/cpp2uno.cxx |6 ++
bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx |3 ++-
2 files changed, 8 insertions(+), 1 deletion(-)
New commits:
commit e13dc26e394ede799a60691638971cf1d9689f74
Author: Jani Monoses j...@ubuntu.com
Date: Tue Feb 21 01:15:02 2012 +0200
ARM bridge: fixes for passing double arguments on the stack
diff --git a/bridges/source/cpp_uno/gcc3_linux_arm/cpp2uno.cxx
b/bridges/source/cpp_uno/gcc3_linux_arm/cpp2uno.cxx
index 07bdea1..9750b6a 100644
--- a/bridges/source/cpp_uno/gcc3_linux_arm/cpp2uno.cxx
+++ b/bridges/source/cpp_uno/gcc3_linux_arm/cpp2uno.cxx
@@ -70,6 +70,7 @@ namespace
char * pCppStack = pTopStack;
#ifdef __ARM_PCS_VFP
+int dc = 0;
char * pFloatArgs = (char *)(pCppStack - 64);
#endif
// return
@@ -152,6 +153,11 @@ namespace
if ((pFloatArgs - pTopStack) % 8)
pFloatArgs+=sizeof(float); //align to 8
pCppArgs[nPos] = pUnoArgs[nPos] = pFloatArgs;
pFloatArgs += sizeof(double);
+if (++dc == arm::MAX_FPR_REGS) {
+if (pCppStack - pTopStack 16)
+pCppStack = pTopStack + 16;
+pFloatArgs = pCppStack;
+}
} else
#endif
pCppArgs[nPos] = pUnoArgs[nPos] = pCppStack;
diff --git a/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx
b/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx
index 8e69ebe..98b29ba 100644
--- a/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx
+++ b/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx
@@ -362,7 +362,8 @@ void callVirtualMethod(
{ \
++pDS; \
} \
-*pDS++ = *reinterpret_castdouble *( pSV );\
+*(double *)pDS = *reinterpret_castdouble *( pSV );\
+pDS += 2;\
}
#else
#define INSERT_FLOAT( pSV, nr, pFPR, pDS ) \
___
Libreoffice-commits mailing list
Libreoffice-commits@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
