Hi Lewis,
If I understand the generated assembler code correctly, the call to
_$_Q2t14epicsSingleton1Z13localHostName9reference (which is
epicsSingleton<localHostName>::reference::~reference(void) in clear
text) happens in the exception rollback code of the cac constructor.
When optimization is enabled, the ~reference destructor is inlined. But
when optimization is disabled, the call contains a function call to the
destructor. This creates an instance of the template with weak linkage.
This should not happen when -fno-implicit-templates is enabled. Indeed,
with the Tornado 2.2 compiler it does not happen. I consider this a bug
in the old C++ compiler.
And the generated assembler code from cac.cpp and templateInstances.cpp
is different around the assert call:
cac:
...
addis 9,0,.LC7@ha
addi 3,9,.LC7@l
li 4,103
addis 9,0,.LC8@ha
addi 5,9,.LC8@l
addis 9,0,.LC3@ha
addi 6,9,.LC3@l
bl epicsAssert
...
templateInstances:
...
addis 9,0,.LC7@ha
addi 3,9,.LC7@l
li 4,103
addis 9,0,.LC8@ha
addi 5,9,.LC8@l
li 6,0
bl epicsAssert
...
So what is the difference? The third argument to epicsAssert, which is
the macro epicsAssertAuthor.
In cac, it is .LC3, which is:
.LC3:
.string "Jeff Hill [email protected]"
In templateInstances, it is 0.
This comes from epicsAssert.h:
#ifndef epicsAssertAuthor
# define epicsAssertAuthor 0
#endif
and
# define assert(exp) ((exp) ? (void)0 : \
epicsAssert(__FILE__, __LINE__, #exp, epicsAssertAuthor))
In cac.cpp we find:
#define epicsAssertAuthor "Jeff Hill [email protected]"
But in epicsAssertAuthor is not defined.
So what can we learn from this?
*Do not mix C++ inline code with preprocessor macros!*
This may expand to different code in different contexts but C++ expects
that the same inline function generates the same code everywhere.
Dirk
Dirk Zimoch wrote:
Hi Lewis,
I can reproduce your problem with -O0. No idea what I missed last time.
Indeed I see the symbol multiple times in libca.a:
cac.o:
0000a430 W _$_Q2t14epicsSingleton1Z13localHostName9reference
cacChannel.o:
000010f4 W _$_Q2t14epicsSingleton1Z13localHostName9reference
templateInstances.o:
000127b8 T _$_Q2t14epicsSingleton1Z13localHostName9reference
Two times as "weak" symbol, once explicitly instantiated.
When compiling with -O1, the "weak" symbols are gone. Let me investigate
a bit....
Dirk
J. Lewis Muir wrote:
On 3/15/12 5:45 AM, Dirk Zimoch wrote:
Hello Lewis,
I cannot reproduce your problem. I compiled EPICS 3.14.12.2 with
your cross-compiler and my installation of Tornado 2.0.2 without
any problems.
I created the cross architecture "T202-ppc604". Here is the
config file
base-3.14.12/configure/os/CONFIG.Common.T202-ppc604:
-------------------------------------------------------
include $(CONFIG)/os/CONFIG.Common.vxWorks-ppc604_long
VXWORKS_VERSION = 5.3
WIND_BASE = /afs/psi.ch/project/vxworks/Tornado2.0.2
#there is a problem with our ccppc and optimization
# -O and -O0 work, -O1 and higher are buggy
OPT_CFLAGS_YES = -O3
OPT_CXXFLAGS_YES = -O3
-------------------------------------------------------
I have noticed buggy code creation with -O1 or higher with our
cross compiler for Tornado 2.2. I don't know if your Tornado
2.0.2 compiler has the same problem, too.
I tried all -O levels from 0 to 3 and they compile without errors.
This is how cac.o is built:
/afs/psi.ch/project/vxworks/Tornado2.0.2/host/x86-linux/bin/ccppc -c
-DCPU=PPC604 -DvxWorks=vxWorks -include
/afs/psi.ch/project/vxworks/Tornado2.0.2/target/h/vxWorks.h -O3
-Wall -mlongcall -fno-implicit-templates -fno-builtin -MMD -I.
-I../O.Common -I. -I..
-I/usr/local/epics/base-3.14.12/include/os/vxWorks
-I/usr/local/epics/base-3.14.12/include
-I/afs/psi.ch/project/vxworks/Tornado2.0.2/target/h ../cac.cpp
And here is the building and linking of callbackTest:
/afs/psi.ch/project/vxworks/Tornado2.0.2/host/x86-linux/bin/ccppc -c
-DCPU=PPC604 -DvxWorks=vxWorks -include
/afs/psi.ch/project/vxworks/Tornado2.0.2/target/h/vxWorks.h -O3
-Wall -mlongcall -fno-builtin -MMD -I.
-I../O.Common -I. -I..
-I/usr/local/epics/base-3.14.12/include/os/vxWorks
-I/usr/local/epics/base-3.14.12/include
-I/afs/psi.ch/project/vxworks/Tornado2.0.2/target/h
../callbackTest.c
/afs/psi.ch/project/vxworks/Tornado2.0.2/host/x86-linux/bin/ldppc -r
-o callbackTest -L/usr/local/epics/base-3.14.12/lib/T202-ppc604/
-L/afs/psi.ch/project/vxworks/Tornado2.0.2/host/x86-linux/powerpc-wrs-vxworks/lib
callbackTest.o -ldbIoc -ldbStaticIoc -lca -lCom
/afs/psi.ch/project/vxworks/Tornado2.0.2/host/x86-linux/bin/nmppc
callbackTest
callbackTest.nm
perl /usr/local/epics/base-3.14.12/bin/SL5-x86/munch.pl -o
callbackTest_ctdt.c callbackTest.nm
/afs/psi.ch/project/vxworks/Tornado2.0.2/host/x86-linux/bin/ccppc -c
-DCPU=PPC604 -DvxWorks=vxWorks -include
/afs/psi.ch/project/vxworks/Tornado2.0.2/target/h/vxWorks.h -O3
-Wall -mlongcall -fno-builtin -MMD -fdollars-in-identifiers -I.
-I../O.Common -I. -I..
-I/usr/local/epics/base-3.14.12/include/os/vxWorks
-I/usr/local/epics/base-3.14.12/include
-I/afs/psi.ch/project/vxworks/Tornado2.0.2/target/h callbackTest_ctdt.c
/afs/psi.ch/project/vxworks/Tornado2.0.2/host/x86-linux/bin/ldppc -r
-o callbackTest.munch callbackTest_ctdt.o callbackTest
Hi, Dirk.
That is really strange. The only possible differences I can
think of are:
1. I set CROSS_COMPILER_TARGET_ARCHS to "vxWorks-68040
vxWorks-ppc603 vxWorks-ppc604 vxWorks-ppc604_long" in
configure/CONFIG_SITE.
2. I applied all patches from the EPICS Base 3.14.12.2 Known
Problems web page.
3. My VXWORKS_VERSION is set to "5.4" in
configure/os/CONFIG_SITE.Common.vxWorksCommon. There's a
note there that says "vxWorks 5.3 (Tornado 1.x) is not
supported." You have it set to "5.3". Also, I set it in
configure/os/CONFIG_SITE.Common.vxWorksCommon, but you set it
in configure/os/CONFIG.Common.T202-ppc604.
4. I set OPT_CFLAGS_YES and OPT_CXXFLAGS_YES to "-O0" in
configure/os/CONFIG.Common.vxWorksCommon, but you set them in
configure/os/CONFIG.Common.T202-ppc604.
If you were to do all of these and were still unable to
reproduce the problem, I would guess something must be different
between our systems in the parts we have not shared.
Thanks,
Lewis
J. Lewis Muir wrote:
Hi, Dirk.
On 3/14/12 5:51 AM, Dirk Zimoch wrote:
What is your gcc version?
The GCC that comes with my host OS is
$ gcc --version | head -n 1
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51)
The GCC for my host in Tornado 2.0.2 is
$ cd /opt/vxworks-tornado-2.0.2/host/x86-linux/bin
$ ./m68k-wrs-vxworks-gcc --version
cygnus-2.7.2-960126 egcs-971225 t202/SNS-patched
$ powerpc-wrs-vxworks-gcc --version
cygnus-2.7.2-960126 egcs-971225 t202/SNS-patched
Can you send me a tar of your
/opt/vxworks-tornado-2.0.2/host/x86-linux directory?
Sure. It's at
https://www.imca.aps.anl.gov/~jlmuir/tmp2/tornado-2.0.2-x86-linux.tar.gz
I should note that I probably will just end up upgrading to
Tornado 2.2, so I don't want you to spend too much time on this
for my sake. But if it's something you're interested in
tracking down, I'm happy to keep trying things you suggest and
providing things you ask for.
Thanks for all your help!
Lewis
Dirk Zimoch wrote:
Lewis,
I am taking this off the tech-talk list for the moment.
I tried to compile 3.14.12.2 for tornado 2.0.2 and failed much
earlier. I have to admit that I don't have a Linux compiler
for Tornado 2.0.2. So I hacked the Makefile to use the
compiler from Tornado 2.2. But that does not explain what I
see:
When compiling src/libCom/fdmgr/fdmgr.cpp
In file included from
../../../src/libCom/osi/os/vxWorks/osdSock.h:29,
from ../../../src/libCom/osi/osiSock.h:21,
from ../../../src/libCom/fdmgr/fdManager.h:28,
from ../../../src/libCom/fdmgr/fdmgr.cpp:29:
/afs/psi.ch/project/vxworks/Tornado2.0.2/target/h/netinet/in.h:195:
ANSI C++ forbids data member `ip_opts' with same name as
enclosing class
So to me it seems that there are problems with Tornado2.0.2
vxWorks headers and EPICS 3.14.12.2.
Have you seen that problem and fixed it?
Dirk
J. Lewis Muir wrote:
When building EPICS Base 3.14.12.2 (+ Known Problems patches)
for vxWorks-ppc603, vxWorks-ppc604, and
vxWorks-ppc604_long, I'm
getting warnings like this:
===
/opt/vxworks-tornado-2.0.2/host/x86-linux/bin/ldppc -r -o
callbackTest -L../../../../lib/vxWorks-ppc603/
-L/opt/vxworks-tornado-2.0.2/host/x86-linux/powerpc-wrs-vxworks/lib
callbackTest.o -ldbIoc -ldbStaticIoc -lca -lCom
Warning: size of symbol
`_$_Q2t14epicsSingleton1Z13localHostName9reference' changed
from
160 to 164 in cac.o
Warning: size of symbol
`__rf__Q2t14epicsSingleton1Z13localHostName9reference' changed
from 128 to 132 in cac.o
===
When building for vxWorks-ppc604_long, there are more of these
warnings than for the other vxWorks targets. Some warnings do
not appear to be related to callbackTest.c (which is test
code).
Attached is a complete build log showing all warnings.
Searching for the string "Warning: size of symbol" will
find the
relevant warnings.
The build host is running RHEL Client 5.7. The VxWorks
Tornado
2.0.2 environment is from the APS.
Searching the web I found this:
http://gcc.gnu.org/ml/gcc-help/2001-03/msg00167.html
I don't know if that helps.
Are these warnings a problem?
Thanks,
Lewis
- Replies:
- Re: "Size of symbol changed" warnings building EPICS Base 3.14.12.2 Andrew Johnson
- References:
- "Size of symbol changed" warnings building EPICS Base 3.14.12.2 J. Lewis Muir
- Navigate by Date:
- Prev:
RE: Macro for workspace directory? Chen, Xihui
- Next:
Re: 32-bit TIFFs and PIL Matt Newville
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
<2012>
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: "Size of symbol changed" warnings building EPICS Base 3.14.12.2 Andrew Johnson
- Next:
Re: "Size of symbol changed" warnings building EPICS Base 3.14.12.2 Andrew Johnson
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
<2012>
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|