Hi Ben,
I have added some runtime checks to the generated registerRecordDeviceDriver routine and to iocInit for a few things such as whether TOP is the same, but I don't think it's possible to do what you want.
We don't know at compile-time that you aren't planning to load the xyz module from some other .munch file or lib.so shared library (and although I don't particularly recommend it, that is something which Dirk Zimoch wants to be able to do). Now I could conceive of some kind of optional way to test your binary for completeness(which Dirk would not use), but for VxWorks that would require that we know all of the symbols that your specific VxWorks boot image provides since those are symbols which are supposed to be undefined in your .munch file.
That seems like it might be half-way to us creating a fully bootable image file containing both the IOC application code and the VxWorks OS, but I don't think that would be quite as easy as it might seem because getting initialization right (C++ static initializers for our code) could be tricky. Has anyone ever tried to do that?
- Andrew
--
Sent from my iPad
On Jun 28, 2013, at 3:07 PM, Benjamin Franksen <[email protected]> wrote:
> Hi
>
> it just happened to me for the second time: I deleted some unused code and
> forgot to delete a corresponding line in the dbd file. It was a test stand and
> it crashed even before iocInit and there was a warning before it happened, so
> no damage, but still...
>
> The line in the dbd file is a registrar entry, something like
>
> registrar(xyz)
>
> that registers some shell commands. This line is buried inside a support
> module's dbd so the application's dbd file can include it. So it is quite easy
> to forget to remove this line when you delete the code that implements the
> xyz. There is no warning whatsoever until the IOC is run. Then you get:
>
> Undefined symbol: pvar_func_xyz (binding 1 type 0)
>
> and later:
>
> TESTIOC1C_registerRecordDeviceDriver(pdbbase)
>
> VME Bus Error accessing A32: 0x8c3f6f40
> machine check
> Exception next instruction address: 0x8c3f6f40
> Machine Status Register: 0x0008b030
> Condition Register: 0x48200082
> Task: 0x1d32f98 "tShell"
>
> (The observed behaviour is of course to be expected.)
>
> Is there a way to somehow warn the user at compile time that there is a
> mismatch between the dbd file and the binary?
>
> Note: This is with EPICS base R3.14.12.2 and vxWorks 5.4.2.
>
> Cheers
> --
> Ben Franksen
> () ascii ribbon campaign - against html e-mail
> /\ www.asciiribbon.org - against proprietary attachm€nts
- Replies:
- Re: registerRecordDevice... crashes IOC during startup Benjamin Franksen
- Re: registerRecordDevice... crashes IOC during startup Dirk Zimoch
- Re: registerRecordDevice... crashes IOC during startup Ron Sluiter
- References:
- registerRecordDevice... crashes IOC during startup Benjamin Franksen
- Navigate by Date:
- Prev:
RE: Record Processing Mark Rivers
- Next:
Updating the RDB archiver at the STAR experiment L. C. De Silva
- 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:
registerRecordDevice... crashes IOC during startup Benjamin Franksen
- Next:
Re: registerRecordDevice... crashes IOC during startup Benjamin Franksen
- 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
|