Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Sat, 29 Jun 2013 12:09:40 -0500 (CDT)

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System