gcc version 4.0.2 20050901 (prerelease) (SUSE Linux)

kr: citation from http://www.gnu.org/software/libc/manual/html_node/Argument-Macros.html

But va_list is an opaque type and one cannot necessarily assign the value of one variable of type va_list to 
another variable of the same type.

This should work:

#ifdef __va_copy
        __va_copy (m_param, param);
#else
        m_param = param;
#endif

in fact it at least compiles here and then:

/data/oo/BuildDir/ooo_SRC680_m212_src/cppu/source/uno/EnvStack.cxx: In function 'void s_pull
(__va_list_tag*)':
/data/oo/BuildDir/ooo_SRC680_m212_src/cppu/source/uno/EnvStack.cxx:231: warning: cannot 
receive objects of non-POD type 'struct __va_list_tag [1]' through '...'; call will abort at runtime
/data/oo/BuildDir/ooo_SRC680_m212_src/cppu/source/uno/EnvStack.cxx:231: error: invalid initializer
/data/oo/BuildDir/ooo_SRC680_m212_src/cppu/source/uno/EnvStack.cxx: In function 'void 
s_environment_invoke_vv(__va_list_tag*)':
/data/oo/BuildDir/ooo_SRC680_m212_src/cppu/source/uno/EnvStack.cxx:281: warning: cannot 
receive objects of non-POD type 'struct __va_list_tag [1]' through '...'; call will abort at runtime
/data/oo/BuildDir/ooo_SRC680_m212_src/cppu/source/uno/EnvStack.cxx:281: error: invalid initializer
dmake:  Error code 1, while making '../../unxlngx6.pro/slo/EnvStack.obj'

In EnvStack.cxx, the problem is:

        uno_EnvCallee * pCallee = va_arg(param, uno_EnvCallee *);
        va_list         xparam  = va_arg(param, va_list);

        pCallee(xparam);

It should probably read

        uno_EnvCallee * pCallee = va_arg(param, uno_EnvCallee *);
        va_arg(param, va_list);

        pCallee(param);

But I do not know what is in param. This one extects, we have to skip one argument after pCallee 
itself...

va_arg docs says:

--- cut here ---
* Macro: type va_arg (va_list ap, type)

The va_arg macro returns the value of the next optional argument, and modifies the value of ap to 
point to the subsequent argument. Thus, successive uses of va_arg return successive optional 
arguments.
--- cut here ---

So probably we skip one argument *after* pCallee unintentionally?

So, is simple

uno_EnvCallee * pCallee = va_arg(param, uno_EnvCallee *);
pCallee(param);

enough?

Pavel,

your first fix regarding the use of "__va_copy_" looks reasonable. Unfortunately
the second one does not ;-( Are their any buildbots or similar where I can
reproduce the problem to fix this?

Regards

  Kay

Created attachment 45141 [details]
Fix for gcc 64

Pavel, could you try the attached patch? It at least compiles on 32bit ... ;-)

Reassigned to me.

started ...

cc

Will do immediatelly after dinner - ~30 minutes.

Yes, the patch fixed also the second break.

With fixed /tmp/AffineBridge.cxx I now get this:

Making: ../unxlngx6.pro/lib/libunsafe_uno_uno.so
ccache /usr//bin/g++ -Wl,-z,combreloc -Wl,-z,defs -Wl,-rpath,'$ORIGIN' -shared -L../unxlngx6.pro/
lib -L../lib -L/data/oo/BuildDir/ooo_SRC680_m212_src/solenv/unxlngx6/lib -L/data/oo/BuildDir/
ooo_SRC680_m212_src/solver/680/unxlngx6.pro/lib -L/data/oo/BuildDir/ooo_SRC680_m212_src/
solenv/unxlngx6/lib -L/opt/java/lib64 -L/opt/java/jre/lib/amd64 -L/opt/java/jre/lib/amd64/server -
L/opt/java/jre/lib/amd64/native_threads -L/usr/X11R6/lib64 ../unxlngx6.pro/slo/UnsafeBridge.o ../
unxlngx6.pro/slo/unsafe_uno_uno_version.o ../unxlngx6.pro/slo/unsafe_uno_uno_description.o -o ../
unxlngx6.pro/lib/libunsafe_uno_uno.so -luno_purpenvhelpergcc3 -luno_cppu -luno_salhelpergcc3 -
luno_sal -ldl -lpthread -lm -Wl,-Bdynamic -lstlport_gcc
../unxlngx6.pro/slo/UnsafeBridge.o: In function `uno_ext_getMapping':
/data/oo/BuildDir/ooo_SRC680_m212_src/cppu/source/UnsafeBridge/UnsafeBridge.cxx:169: 
undefined reference to `cppu::helper::purpenv::createMapping(_uno_Mapping**, _uno_Environment*, 
_uno_Environment*, void (*)(bool, void*, void*, _typelib_TypeDescriptionReference*, 
_typelib_MethodParameter*, int, _typelib_TypeDescription const*, void*, void**, _uno_Any**), void*)'
collect2: ld returned 1 exit status
dmake:  Error code 1, while making '../unxlngx6.pro/lib/libunsafe_uno_uno.so'

Created attachment 45152 [details]
AffineBridge diff

BTW - contact me on IRC tomorrow - I'll give you remote ssh access to such machine.

Created attachment 45222 [details]
Final fix for gcc x86-64

Created attachment 45223 [details]
Support for a x86-64 map file for the purpenvhelper

Created attachment 45224 [details]
The actual gcc linux x86-64 purpenvhelper mapfile.

I added two patches:
* EnvStack.cxx.patch.final
* util_makefile.mk.patch.final

and a new map file:
* util_uno_purpenvhelpergcc3.X86_64.map

The previous fix for EnvStack.cxx was _wrong_ .

Pavel, I also fixed the unit tests on your box, feel free to check these in,
otherwise I am going to do so in another CWS.

kr: I do not like to have a different map file for 64bit platforms. This would be the first example of such 
specific map file. So far, it was enough to have one such file.

IIRC on Linux, nonexistent symbols are ignored, so we can just add the new symbol to the original gcc3 
map file, no?

sb: what is your opinion on this?

cppu.diff that I'll attach contains complete diff I have now. With it, testcppu also succeeds.

Lowering prio, as the fix is known.

sb: please read the previous comment. I forgot to add you to CC in one step, sorry.

Created attachment 45230 [details]
complete cppu diff I use now

Not that easy. The mapfile written this way would broke cppu build on Mac OS X because of non-existent 
symbol.

Just use '?' (question mark) in the map file where both symbols differ (i and l). Verifying this fix now on all 
systems again...

Created attachment 45239 [details]
revised complete diff (for testing)

With this, OOo compiles completely, but...

I build with many languages and in the final instsetoo_native build, in the middle of packing, I get error 
(in the e.g. 7th language):

Registering python UNO components:
######################################################
SUCCESS: Source for types.rdb: /data/oo/BuildDir/ooo_SRC680_m212_src/solver/680/unxlngx6.pro/
bin/types.rdb
SUCCESS: Source for pyuno_services.rdb: /data/oo/BuildDir/ooo_SRC680_m212_src/solver/680/
unxlngx6.pro/bin/pyuno_services.rdb
Systemcall:  /data/oo/BuildDir/ooo_SRC680_m212_src/solver/680/unxlngx6.pro/bin/regcomp -
register -br /data/oo/BuildDir/ooo_SRC680_m212_src/solver/680/unxlngx6.pr
o/bin/types.rdb -br /data/oo/BuildDir/ooo_SRC680_m212_src/solver/680/unxlngx6.pro/bin/
pyuno_services.rdb -r /data/oo/BuildDir/ooo_SRC680_m212_src/instsetoo_nativ
e/unxlngx6.pro/OpenOffice/deb/services.rdb/fi_inprogress_1/services.rdb -c 
vnd.openoffice.pymodule:mailmerge -l com.sun.star.loader.Python 2>&1 |
vnd.openoffice.pymodule:mailmerge
register component 'vnd.openoffice.pymodule:mailmerge' in registry '/data/oo/BuildDir/
ooo_SRC680_m212_src/instsetoo_native/unxlngx6.pro/OpenOffice/deb/services.r
db/fi_inprogress_1/services.rdb' succesful!
ERROR:  /data/oo/BuildDir/ooo_SRC680_m212_src/solver/680/unxlngx6.pro/bin/regcomp -register -
br /data/oo/BuildDir/ooo_SRC680_m212_src/solver/680/unxlngx6.pro/bin
/types.rdb -br /data/oo/BuildDir/ooo_SRC680_m212_src/solver/680/unxlngx6.pro/bin/
pyuno_services.rdb -r /data/oo/BuildDir/ooo_SRC680_m212_src/instsetoo_native/unx
lngx6.pro/OpenOffice/deb/services.rdb/fi_inprogress_1/services.rdb -c 
vnd.openoffice.pymodule:mailmerge -l com.sun.star.loader.Python 2>&1 |
Systemcall:  /data/oo/BuildDir/ooo_SRC680_m212_src/solver/680/unxlngx6.pro/bin/regcomp -
register -br /data/oo/BuildDir/ooo_SRC680_m212_src/solver/680/unxlngx6.pr
o/bin/types.rdb -br /data/oo/BuildDir/ooo_SRC680_m212_src/solver/680/unxlngx6.pro/bin/
pyuno_services.rdb -r /data/oo/BuildDir/ooo_SRC680_m212_src/instsetoo_nativ
e/unxlngx6.pro/OpenOffice/deb/services.rdb/fi_inprogress_1/services.rdb -c 
vnd.openoffice.pymodule:pythonscript -l com.sun.star.loader.Python 2>&1 |
vnd.openoffice.pymodule:pythonscript
register component 'vnd.openoffice.pymodule:pythonscript' in registry '/data/oo/BuildDir/
ooo_SRC680_m212_src/instsetoo_native/unxlngx6.pro/OpenOffice/deb/service
s.rdb/fi_inprogress_1/services.rdb' succesful!
SUCCESS:  /data/oo/BuildDir/ooo_SRC680_m212_src/solver/680/unxlngx6.pro/bin/regcomp -register 
-br /data/oo/BuildDir/ooo_SRC680_m212_src/solver/680/unxlngx6.pro/b
in/types.rdb -br /data/oo/BuildDir/ooo_SRC680_m212_src/solver/680/unxlngx6.pro/bin/
pyuno_services.rdb -r /data/oo/BuildDir/ooo_SRC680_m212_src/instsetoo_native/u
nxlngx6.pro/OpenOffice/deb/services.rdb/fi_inprogress_1/services.rdb -c 
vnd.openoffice.pymodule:pythonscript -l com.sun.star.loader.Python 2>&1 |

Moved directory from /data/oo/BuildDir/ooo_SRC680_m212_src/instsetoo_native/unxlngx6.pro/
OpenOffice/deb/services.rdb/fi_inprogress_1 to /data/oo/BuildDir/ooo_SRC
680_m212_src/instsetoo_native/unxlngx6.pro/OpenOffice/deb/services.rdb/fi_witherror_1

Removing directory /data/oo/BuildDir/ooo_SRC680_m212_src/instsetoo_native/unxlngx6.pro/
OpenOffice/deb/zip/fi

Removing directory /data/oo/BuildDir/ooo_SRC680_m212_src/instsetoo_native/unxlngx6.pro/
OpenOffice/deb/services.rdb/fi_witherror_1

***************************************************************
ERROR: Could not register all components!
in function: create_services_rdb
***************************************************************

This could be something else, but it is strange.

Pavel, it seems that "sal_Int32" is mapped to "int" on x86-64 while it is mapped
to "long" on x86-32. Resulting in different marshalling etc. 
Is this intentionally? AFAIK, "int" is four bytes of length on both platforms
(By the way, SB is on vacation this week)

kr: yes, it is intentional. It can't be long, because long is 8 bit on x86-64, thus it had to be changed to int 
on x86-64.

And as it is long on x86, we can't change it to long there because of the same reasons (ABI changes).

Ahh, I think I understand: "sal_Int32" being "long" on x86 is the bug. -> I
would be able to replace "sal_Int32" with "int" and everything would be fine
(though I think the natural size would be long, but anyway ;-), while the API
wouldn't look as it ought to be. (The real reason for this bug being is that
"typedef"s are only aliases).

Pavel, I just talked to Thorsten Behrens about adding dedicated map files (where
needed) for the x86-64, and he has the same opinion as I have, that this is the
right thing to do. What makes you thing that this would be wrong?

only the maintenance burden - only just for one letter/type difference in one function...

*** Issue 77909 has been marked as a duplicate of this issue. ***

*** Issue 77910 has been marked as a duplicate of this issue. ***

Pavel, I actually think that the maintenance burden is higher, if  trying to use
the same map file even if it needs to be differentiated by platform. -> Going to
fix this by adding a new map file.

The same problem should already have arisen in older cppuhelper, for example,
where cppu::PropertySetMixinImpl::getFastPropertyValue(sal_Int32)
(cppuhelper/inc/cppuhelper/propertysetmixin.hxx:1.5 l. 395) is listed as
_ZThn4_N4cppu20PropertySetMixinImpl20getFastPropertyValueEl with an explicit "l"
for "long" at cppuhelper/source/gcc3_linux_intel.map:1.14 l. 355.  How has the
problem been solved there?

Going to fix this in "unomacli64" ...

cmc->sb: We accidentally entirely missed using a map for x86_64 in the other
case you mentioned, i.e. we're falling through to a "don't use a map" case in
cppuhelper/source/makefile.mk theres

.ELIF "$(OS)$(CPU)$(COMNAME)"=="LINUXIgcc3"
SHL1VERSIONMAP=gcc3_linux_intel.map

but we have no x86_64 equivalent of e.g.

.ELIF "$(OS)$(CPU)$(COMNAME)"=="LINUXXgcc3"
SHL1VERSIONMAP=gcc3_linux_64bit.map

I should probably add a 64bit linux one to that module in another issue

@cmc:  I see.  salhelper/source/makefile.mk:1.26 similarly misses LINUXXgcc3,
with a similarly problematic
salhelper::ConditionWaiter::ConditionWaiter(salhelper::Condition&,sal_uInt32)
export.

@*:  So, we settled on creating specific map files for LINUXXgcc3 where
necessary, instead of massaging the existing LINUXIgcc3 ones?  Fine with me. 
(Although with Mac OS X we took the other route, on the grounds that each
additional map file is a maintenance burden, so if we can reduce the number of
map files with only mild trickery, that is not without benefits either.)

@kr:  va_copy is in C99, so maybe we can assume it is available everywhere
instead of conditionally using either __va_copy or some construct that is not
guaranteed to do anything sensible, even if it compiles (i.e., assignment
between va_list values).  (Then again, va_copy can only be called if va_end is
also called *in the same function*, see the C99 Standard, so the whole code is
probably dubious, anyway.)

->SB: Trying to avoid that "va_copy" altogether ...

FWIW I'd be in favour of adding trickery, ? for i/l and ? for 4/8 where
relevant, but I'm easy about it. If we go a separate mapfile can I suggest that
we call it "gcc3_unix_64bit.map" rather than e.g. gcc3_linux_x86-64.map.
Whatever way we go here I can fix up the same way the other map files that we
never thought of under issue 77975.

->CMC: Actually I am more a fan of using some (env) variables to identify the
correct mapping file, e.g. <name>.$(CPUNAME).map or
<name>.$(COM).$(CPPUNAME).map - you get what I mean. 

What I really don't like is something as:
.IF "$(COMNAME)"=="msci"
SHL1VERSIONMAP=msvc_win32_intel.map
.ELIF "$(COMNAME)"=="sunpro5"
SHL1VERSIONMAP=cc5_solaris_sparc.map
.ELIF "$(OS)$(CPU)$(COMNAME)"=="LINUXIgcc3"
SHL1VERSIONMAP=gcc3_linux_intel.map
.ELIF "$(OS)$(CPU)$(COMNAME)"=="FREEBSDIgcc3"
SHL1VERSIONMAP=gcc3_linux_intel.map
.ELIF "$(OS)$(CPU)$(COMNAME)"=="LINUXSgcc3"
SHL1VERSIONMAP=gcc3_linux_intel.map
.ELIF "$(OS)$(CPU)$(COMNAME)"=="MACOSXIgcc3"
SHL1VERSIONMAP=gcc3_linux_intel.map
.ELIF "$(GUI)$(COM)"=="WNTGCC"
SHL1VERSIONMAP=mingw.map
.ENDIF

If map files share symbols, we should create a common map file and include  it
somehow.

Would that be OK for you?

I don't feel strongly about it, just so long as it doesn't become a huge
time-sink task :-)

With this patch applied, OOo dies horribly on x86_64.

here is the stack trace

#0  0x00002b7c63fde90a in typelib_typedescription_register () from
/home/hub/OOinstall/vanilla/program/libuno_cppu.so.3
#1  0x00002b7c63e3aa3b in com::sun::star::container::cppu_detail_getUnoType ()
from /home/hub/OOinstall/vanilla/program/libuno_cppuhelpergcc3.so.3
#2  0x00002b7c63e3aea9 in com::sun::star::container::cppu_detail_getUnoType ()
from /home/hub/OOinstall/vanilla/program/libuno_cppuhelpergcc3.so.3
#3  0x00002b7c63e4f57e in cppu::addFactories () from
/home/hub/OOinstall/vanilla/program/libuno_cppuhelpergcc3.so.3
#4  0x00002b7c63e34966 in cppu::bootstrapInitialSF () from
/home/hub/OOinstall/vanilla/program/libuno_cppuhelpergcc3.so.3
#5  0x00002b7c63e50389 in cppu::(anonymous
namespace)::defaultBootstrap_InitialComponentContext ()
   from /home/hub/OOinstall/vanilla/program/libuno_cppuhelpergcc3.so.3
#6  0x00002b7c63e51064 in cppu::defaultBootstrap_InitialComponentContext () from
/home/hub/OOinstall/vanilla/program/libuno_cppuhelpergcc3.so.3
#7  0x000000000043472a in desktop::Desktop::CreateApplicationServiceManager ()
#8  0x000000000041d13b in desktop::Desktop::Init ()
#9  0x00002b7c628f822d in InitVCL () from
/home/hub/OOinstall/vanilla/program/libvcl680lx.so
#10 0x00002b7c628f848a in Window::RequestHelp () from
/home/hub/OOinstall/vanilla/program/libvcl680lx.so
#11 0x00002b7c628f8685 in SVMain () from
/home/hub/OOinstall/vanilla/program/libvcl680lx.so
#12 0x000000000041b9cf in main ()

dies on startup. 

kr: wrt. the patch, I did not try it yet & did not look too well either, but 
typeof(param[0]) * xparam  = va_arg(param, typeof(param[0]) *); looks very 
suspicious to me :-)

On x86-64, some of the parameters (6 ints, 8 floats) are stored in registers, 
va_list is then a structure that points to an area where they are saved; more
in http://www.x86-64.org/documentation/abi.pdf, 3.34.

Didn't you want to do something like va_list xparam = va_copy( va_arg(param, 
va_list) ) instead, and avoid the *va_list?

But maybe I am completely wrong :-)

Confirmed the same horrible death on FreeBSD/amd64. :-(

Guys, I think the problem is basically solved, actually completely avoiding
va_copy etc. I am quite busy currently, but plan to check in the fixes tomorrow
afternoon. Hope that is OK for you. 

I am likely adding i77991 to unomacli64 as well, though it seems to be an
independent bug, only becoming visible by introducing the threading model
changes in m212.


 Kay

I checked in the fixes for the affine_uno bridge and triggered a build on
Solaris SPARC. Linux buildbots seem to be offline, going to try again tomorrow.

kr: It seems there are some missing pieces.  See the attachment.

Created attachment 45681 [details]
Plug missing pieces.

Jkim, you are right, forget to check in the fixes for "bridges" and "cppuhelper"
- done now.

So, everything should work now - executed all tests (as far as they are not
broken) on unxsols4, unxlngi6.pro, wntmsci10.pro. -> Pavel, you want to give it
a try on x86-64.

.

Pavel, have you tried this already? Unfortunately takes a little time to set up
x64 and get used to it ;-)

Yes. cws unomacli64 builds, but there still is another issue #i78284#.

->Pavel, so #i78284# still happens on unomacli64 ? 

yes, as I said there at the end of comment #1.

I applied the last 2 patches to m216 and it fails with this:

ccache g++  -Wreturn-type -fmessage-length=0 -c -O2 -fno-strict-aliasing
-Wuninitialized   -I.  -I../unxlngx6.pro/inc/cppuhelper
-I../unxlngx6.pro/inc/cppuhelper -I../unxlngx6.pro/inc/private -I../inc
-I../inc/pch -I../inc/cppuhelper -I../inc -I../unx/inc -I../unxlngx6.pro/inc -I.
-I/home/hub/novell/OpenOffice2-m215/solver/680/unxlngx6.pro/inc/stl
-I/home/hub/novell/OpenOffice2-m215/solver/680/unxlngx6.pro/inc/external
-I/home/hub/novell/OpenOffice2-m215/solver/680/unxlngx6.pro/inc
-I/home/hub/novell/OpenOffice2-m215/solenv/unxlngx6/inc
-I/home/hub/novell/OpenOffice2-m215/solenv/inc
-I/home/hub/novell/OpenOffice2-m215/res
-I/home/hub/novell/OpenOffice2-m215/solver/680/unxlngx6.pro/inc/stl
-I/home/hub/novell/OpenOffice2-m215/solenv/inc/Xp31 -I/usr/include
-I/usr/X11R6/include      -I. -I../res -I. -pipe  -Wno-ctor-dtor-privacy
-fno-use-cxa-atexit -fvisibility-inlines-hidden    -fpic -DLINUX -DUNX -DVCL
-DGCC -DC341 -DX86_64 -DCVER=C341 -DNPTL -DGLIBC=2 -DX86_64 -D_PTHREADS
-D_REENTRANT -DNEW_SOLAR -D_USE_NAMESPACE=1 -DSTLPORT_VERSION=400
-DHAVE_GCC_VISIBILITY_FEATURE -D__DMAKE -DUNIX -DCPPU_ENV=gcc3
-DGXX_INCLUDE_PATH=/usr/include/c++/4.1.0 -DSUPD=680 -DPRODUCT -DNDEBUG
-DPRODUCT_FULL -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DCUI -DSOLAR_JAVA -DSRC680=SRC680
  -DSHAREDLIB -D_DLL_   -fexceptions -fno-enforce-eh-specs -DEXCEPTIONS_ON  -o
../unxlngx6.pro/slo/component_context.o
/home/hub/novell/OpenOffice2-m215/cppuhelper/source/component_context.cxx 
/home/hub/novell/OpenOffice2-m215/cppuhelper/source/component_context.cxx: In
function 'com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext>
cppu::createComponentContext(const cppu::ContextEntry_Init*, sal_Int32, const
com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext>&)':
/home/hub/novell/OpenOffice2-m215/cppuhelper/source/component_context.cxx:899:
error: invalid conversion from 'void (*)(__va_list_tag (*)[1])' to 'void
(*)(__va_list_tag*)'
/home/hub/novell/OpenOffice2-m215/cppuhelper/source/component_context.cxx:899:
error:   initializing argument 1 of 'void
com::sun::star::uno::Environment::invoke(void (*)(__va_list_tag*), ...) const'
dmake:  Error code 1, while making '../unxlngx6.pro/slo/component_context.obj'
---* tg_merge.mk *---

ERROR: Error 65280 occurred while making
/home/hub/novell/OpenOffice2-m215/cppuhelper/source
dmake:  Error code 1, while making 'build_instsetoo_native'

->HUB, please c/o the CWS unomacli64, the patches don't reflect the latest state ...

with the whole workspace in m216 it works.

Verified in unomacli64.

Issue confirmed on Linux PowerPC too 

Closing ...