Re: symLib

[Andrew Johnson <anj@aps.anl.gov>]

Tatiana,

I have some good news for you, and some bad news.  It is a pity that you
didn't mention that you were going to do this LynxOS port on this mailing
list before now, for reasons that I will explain below.

The good news is that Marty Kraimer <mrk@aps.anl.gov> is working on making
the necessary modifications to EPICS to solve the problem that you have
discovered with EPICS' widespread use of symLib and the vxWorks system
symbol table.  This has been one of the main things that has stopped ports
of EPICS to other real-time operating systems before now.  Marty has been
planning this work for quite a long time, and is currently implementing it
in between other tasks.  You can read about the current state of his
proposals in the document "Porting iocCore" at
http://www.aps.anl.gov/asd/people/kraimer/iocCorePort.html - the
replacement for the symbol table is what Marty calls the Registry.

You will realize from reading that document though that the bad news is
that much of the work you have already done in porting to LynxOS may have
been wasted in the long run, although some of it will probably be useful. 
I think I can probably speak for the EPICS collaboration as a whole when I
say that we would be very interested in EPICS having the ability to use
LynxOS to run IOCs, but this should be done from a single codebase for
iocCore with Operating System specific routines being enclosed in an
Operating System Independent layer, which is exactly what Marty is working
on.

That said, I will try and answer your specific questions, although my
answers will probably not solve the main problem.

> 1-st question :
> ---------------
> IOC uses system symbol table which spawned by
> tornado/target/config/mv167/symTabl.c

The IOC software uses the symbol table that is generated automatically by
the vxWorks loader - this is part of the OS, not something that comes with
EPICS.  At vxWorks boot time the OS makes entries in the system symbol
table that correspond to all the interfaces that it provides for user
programs.  Then the vxWorks startup script asks the loader to read in a
series of object files (.o files as well as libraries) which contain
symbol data and information about any unresolved symbols in that object
file.  This symbol data is also entered into the system symbol table, and
loader fills in the addresses of all unresolved symbols in the newly
loaded binary object.  Thus at runtime the symbols in the system symbol
table are not just those from the config/<bsp>/symTbl.c file but also
those found in the various parts of the iocCore software.

Later in the IOC startup process, the system symbol table is examined by
the various parts of running iocCore software to find the runtime
addresses of the record, device and driver support tables as well as
various others (for example subroutine record functions) as you have
already discovered.

> 2-nd question:
> ----------------
> How can search a pointer (or address) this  symbol table in vxWorks?
> I guess that I can read all SYMBOL structures from this table and create
> area with same structure in iocCore. This area will contain only EPICS
> entries from symbol table.
> 
> So, tornado/target/config/mv167/symTabl.c contains
> SYMBOL standTbl[2424] {   ...   ,};
> vxWorks uses definitions
> typedef SYMTAB *SYMBAB_ID;
> SYMBAB_ID sysSymTbl;
> 
> Please, explain , is the pointer of standTbl disposed in struct
> symtab SYMTAB?

I regard the contents of the config/<bsp>/symTbl.c file as part of the
Operating System which is very specific to vxWorks, and not something I
need to understand or even look at, as it might change for different
target architectures but we only ever access it using the symLib
interface.  I do not think we even have the source code for the routines
that process the standTbl structure - they are proprietary to Wind River
Systems.

For a port to another OS I suggest that you should look at Marty's
proposal document and think about how you would implement the OSI
facilities that he describes in an efficient manner on that OS.  However
this interface is still liable to change if he comes across any problems
while implementing the OSI layer for vxWorks, so I would not start coding
until he has confirmed that these interfaces are sufficient.

- Andrew
-- 
I brake for tail-gaters