Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: Re: "Size of symbol changed" warnings building EPICS Base 3.14.12.2
From: Dirk Zimoch <dirk.zimoch@psi.ch>
To: "J. Lewis Muir" <jlmuir@imca-cat.org>
Cc: EPICS <tech-talk@aps.anl.gov>
Date: Tue, 20 Mar 2012 17:08:04 +0100
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 johill@lanl.gov"

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 johill@lanl.gov"

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  <20122013  2014  2015  2016  2017  2018  2019 
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  <20122013  2014  2015  2016  2017  2018  2019 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·