|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||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|
|<== Date ==>||<== Thread ==>|
|Subject:||Re: registerRecordDevice... crashes IOC during startup|
|From:||Bruce Hill <email@example.com>|
|To:||Ron Sluiter <firstname.lastname@example.org>|
|Date:||Tue, 9 Jul 2013 17:24:59 -0700|
Sorry for the late reply, I was out last week.|
I haven't had occasion to use EPICS with vxWorks, but
I have encountered and resolved these problems of
undefined symbols and c++ initializers with vxWorks
in a prior life.
We were using vxWorks 5.4, and to make undefined
symbols break at build time instead of run time, our first
solution was to do an additional static link with the vxWorks
image during the build, even though we still loaded
the relocatable app into a booted vxWorks.
This worked, but required some customizing of the vxWorks
build system to create a relocatable object which matched the
boot image. You need to do a partial link to pull the libs you'll
need from the vxWorks libraries, but still generate a relocatable
An easier approach from the vxWorks build system
perspective is to create a target that links your relocatable object
into a bootable vxWorks image. That approach probably wouldn't
work well for EPICS as you'd have to run the vxWorks build after
the EPICS build and find some way to point the vxWorks build at
your relocatable EPICS object file. When I did this, we had a single
app with no loadable modules.
Both approaches worked, albeit at different companies, and in both cases
we eventually started booting a single bootable image with vxWorks
and our app as it shaved some time off the bootup.
However, actually running that bootable image containing both vxWorks
and our application which included c++ static initializers, required
some changes both to our c++ code and vxworks. The main problem was
that the c++ static initializers run much earlier with this approach.
As I recall, we had to change to deferred initialization for c++ classes
that relied on some of the vxWorks services that were not available at
the time the initializers were being called. I think we also customized
the vxworks usrKernel.c file so the initializers would be called later after
more of the os was up.
Hope this helps.
On 07/01/2013 07:44 AM, Ron Sluiter wrote:
-- Bruce Hill Member Technical Staff SLAC National Accelerator Lab 2575 Sand Hill Road M/S 10 Menlo Park, CA 94025