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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: registerRecordDevice... crashes IOC during startup |
From: | Bruce Hill <[email protected]> |
To: | Ron Sluiter <[email protected]> |
Cc: | "[email protected]" <[email protected]> |
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 object file. 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. Regards, - Bruce 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 |