Experimental Physics and Industrial Control System
I have been building and using gcc to compile c++ on versions of vxWorks all
the way back to `92 or so, so I have been through several versions and
changes. Most versions of gcc support vxWorks OK as long as all of the code
is compiled with the same compiler. One commercial product that I have used in
the past, RTI Control Shell, shipped a compiler with their product for many
years. At some point, at 2.6 or 2.7 the name mangling changes slowed down and
details of the binary interface became more important. I am talking aout
things like how variables are pushed on the stack, register usage, variable
alignment in structs and classes, lots of stuff under the hood that ld would
not know about.
What we ran into with Epics 3.14 and not 3.13 was not the use of c++ in Epics
but the introduction of heavy use of c++ exceptions. The various versions of
gcc went from one set of functions in the hidden binary interface to another
and back. I had a slide at the San Jose Epics meeting last December that
showed how the exception API changed from version to version. But it is more
complicated than that. Since is vxWorks a multi-thread RTOS, the exception
handler have to be re-entrant and the ones in the gnu libc.a are not. This
matters because an exception might not always be some kind of fatal error but
in fact one way to write a program's normal execution flow. In that case,
destructors must run and each stack frame cleaned up back up to the 'catch'.
The exception handlers that are used by the the 2.7.2 WRS compiler are in the
5.4 kernel. I don't know if 5.3 included them or not. To change the compiler
you would have to change the exception handlers in the kernel. We, at SNS, did
not want to buy the kernel code or write our own version from scratch. If you
have doubts about about this choice, just imagine writing code to implement an
undocumented API and then testing it.
In the end, the conclusion that we came to was that the best way was to pursue
the compiler source under GPL with Wind River. That turned out to be easy
once the right contact at WRS was found. The changes that I made were just to
port the compiler to Linux using an up to date compiler to build it.
Hope this helps.
>I built gcc-2.7.2.3 from the standard source distribution (not WRS), with
>this configuration:
....
>
>I have been using this on Redhat 7.0 to build EPICS 3.13.[1,2,4] for mv167
>and mv177 targets loading vxWorks V5.3 kernels built with the official
>Tornado 1.0 tools on Solaris. I have had no problems.
>
>I tried gcc-2.8.1 first, which produced code which would load, but not
>execute.
>
.....
>I have not tried this with other target architectures, and the only C++
>code built is what's in 3.13 base.
>
>Did you try the standard gcc-2.7.2.3 ?
>
>Did WRS make further changes which are needed for PPC, EPICS 3.14 or
>vxWorks 5.4 ?
- Navigate by Date:
- Prev:
RE: Cross compiler source and patch file for gcc-2.7.2 on Linux dht
- Next:
drvAscii Allan Honey
- 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: Cross compiler source and patch file for gcc-2.7.2 on Linux dht
- Next:
iocsh under Epics r3.14 RTEMS Bill Nolan
- 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