Re: registerRecordDevice... crashes IOC during startup

[Dirk Zimoch <dirk.zimoch@psi.ch>]

On 01.07.2013 05:02, Andrew Johnson wrote:
> Hi Ben,
>
> On Jun 29, 2013, at 4:42 PM, Benjamin Franksen<benjamin.franksen@helmholtz-berlin.de>  wrote:
>
> > > 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.
> > Hmm. I see. I wonder why loading a binary that references undefined symbols is
> > just a warning and not a fatal error, so the startup script would stop at this
> > point. Or, is there a way to make it one? (This is actually more a VxWorks
> > question, not much to do with EPICS).
> I think it is one in later versions (5.5), or it can be made to be one.
Here is the code I use in my module loader:

        int fd, loaderror;
        fd = open(libname, O_RDONLY, 0);
        loaderror = errno;
        if (fd >= 0)
        {
            errno = 0;
            libhandle = loadModule(fd, LOAD_GLOBAL_SYMBOLS);
            if (errno == S_symLib_SYMBOL_NOT_FOUND)
            {
                libhandle = NULL;
            }
            loaderror = errno;
            close (fd);
        }

My loader first checks for dependencies (that have been found by my 
Makefile) and loads them first. Then it loads the code (above the code 
for vxWorks, I have code for Linux and Windows, too). Then it loads the 
dbd file and finally (for EPICS 3.14) it calls the 
*_registerRecordDeviceDriver function.
We do that for years and it works fine for 3.13 and 3.14.

> > OTOH, I could imagine doing just what you said: checking for all symbols to be
> > defined by (additionally) scanning the boot image for symbols. I think we have
> > the tools available, don't we? Do you think it would be possible to hack
> > something up and (optionally) add it to our build rules?
> It shouldn't be too hard; read in all the symbols from the .nm file that was used to create the OS image (I think there is one, if not use the .sym file), then make sure that every undefined symbol in the application's .nm file was defined in the OS one. We have Perl code to do some of those kinds of things, so it's probably not that hard to write the rest.
My module Makefile does something like this to automatically create 
missing epicsExportAddress() calls when I compile 3.13 device support 
for 3.14. It also creates the necessary infrastructure for snl code and 
sub/genSub/aSub records.
(Unfortunately I cannot yet automatically create the wrapper functions 
needed for iocsh callable functions.)
> > > 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?
> > Not me; but isn't that what we do (by default) for RTEMS?
> No quite, we use the build rules from the RTEMS build system to create a bootable RTEMS image that includes the application. The steps for making a VxWorks image are likely to be rather different, although we might be able to pull in the Wind River rules if we understood them enough. However as I said before I don't know how easy is would be to get the VxWorks combination working; we have special initialization code included for RTEMS, some of which has to be a bit different when running with GeSys.
>
> - Andrew