Experimental Physics and
Industrial Control System

Kate Feng <[email protected]> · Mon, 30 Jun 2003 13:48:06 -0400

Dirk Zimoch wrote:

> Hi Kate and all others,
>
> Kate Feng wrote:
>  > ... My wish also gives RTEMS or Linux users an option to dynamically
>  > load a new application code (e.g. ld("new.obj")), which might need a
>  > new record/device/driver support entry table registered (e.g.
>  > new_SRCS += new_registerRecordDeviceDriver.cpp) at run time or even
>  > during an IOC test/development stage, which could occur very often
>  > during a development cycle. I actually found it handy in beamline
>  > applications.
>  > ...
>
> Attached you will find a Linux (UNIX?) implementation of the 'ld'
> command. Just link it to your iocsh. On Linux, it can load shared
> libraries (*.so). Maybe the code has to be modified to run on other
> platforms. I used the 'dlopen' function to implement it.
>
> ld ("foo")
>

I use RTEMS-CEXP,  which has a dynamic loader except it does not support
shared libraries.

>
> Searches LD_LIBRARY_PATH for libfoo.so, foo.so, foo (in this order).
> After loading the code, all C++ constructors of global objects are
> executed (for registering, etc.)
>
> I have not tried it on any other platform.

However,  I  do not think  the shared libraries is  vital  in the  matter of
C++ static constructor.   C++ static constructor will work for function
registration, which is not necessary (e.g. not even  iocsh, dbl, dbpr.....)
using  RTEMS-CEXP though. C++ static constructor was the first
thing I tried  to   register  Record/Device/Driver before I used
<app>_registerRecordDeviceDriver. Because of  the sequence of the
startup.cmd,  it seems to be impossibe to get the C++ static constructor
to work for the registerRecordDeviceDriver.  It has to be executed
after, not before,  the  dbLoadDatabase("dbd/app.dbd")  command.

For example, the following  sequence  in the startup.cmd will work :

ld ("app.obj")     #load the  application codes
dbLoadDatabase("dbd/app.dbd")
app_registerRecordDeviceDriver(pdbbase)

But not the following :

ld("app.obj")
app_registerRecordDeviceDriver(pdbbase)
dbLoadDatabase("dbd/app.dbd")

Ditto , the following will crash :

ld ("app.obj") #C++ static constructor  auto-register the record/device/driver

dbLoadDatabase("dbd/app.dbd")
.......
......
#Oh, no , record/device/driver has to be registered  after the database is
loaded,
not before

Oops!  crash........

Dirk Zimoch  also wrote :
> Unfortunately, registerRecordDeviceDriver is not static nor prefixed by
> <project>_ as you already noticed. And that means, auto register or not,
> you will have name clashes when linking/loading multiple projects on the
> same ioc. Your suggestion of prefixing the name will be a solution.

I did not get a chance to try R3.14.2 yet.   Based on the developer's guide,
one can  use registryRecordTypeAdd(), regsitryDeviceSupportAdd()
and registryDriverSupportAdd()  to dynamically regsiter  each
record (RSET), device (DSET), driver support entry table, respectively,
instead of using only one command.  However,
I suspect it requires developers to build the  applcation as a shared libray.
As what I mentioned earlier that, RTEMS-CEXP does not support
shared libraries.  It requires static-built objects.

Luckily,  R3.14.2 still has  the registerRecordDeviceDriver.pl, which means
that I can still use my existing tools.   As long as the future release  of
EPICS
maintains its  backward-compatiblity  with the  current  release
( R3.14.0beta2 and up) by keeping the  function of
registerRecordDeviceDriver.pl ,  it will work with my applications and tools.

Regards,
Kate

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System