symbols, searching in vxworks
r...@dynres.com
I am trying to use the function symFindByName to locate a program variable without success and am wondering where I'm going wrong.
I can use sysFindByName to search the global vxworks symbol table for the _vxworks_ variables. As an example, the following works from a loaded program or from Tornado:
symFindByName (sysSymTbl, "symFindByName", &address, &type)
This returns the address of the vxworks function 'symFindByName' by searching through the global symbol table (sysSymTbl)
If I load up my program ( ->ld <myprogram.o) and try to find the address of variables there, the function returns an error.
If I use the function lkup from the Tornado shell, I _can_ find my variables.
Can anyone shed any light on this? My bottom line is that I want to provide a way for a program to "monitor" itself in an easily reconfigureable way. My thought is to create a text file that can be read
by the program and the program can then locate variable locations by using the sysFindByName
Ron
Dave Olson
- vxWorks is built w/ or loads it's own symbols onto
the target
- you are using the host shell
- you have not enabled 'symbol table synchronization'
symFindByName() runs on the target and can only find symbols
that are on the target. ld() runs on the host and only
downloads the code, not the symbols. lkup() runs on
the host, so has access to the symbols.
You can enable 'symbol table synchronization' (see the
target server configuration dialog), however it runs as
a background task and is really designed for human speed
interaction. It is really not workable for programmatic
access to the symbols.
Bottom line is that under Tornado 2, you really can't depend
on programmatic use of the VxWorks managed symbol table. I
tried doing so (at a former employer, so can't share the code)
and ended up chucking that approach and writing my own
independent facility that required routines to 'register'
their symbols of interest with a manager. Other routines that
wanted to know about those symbols could then obtain them from
that manager.
> -----Original Message-----
> Sent: Wednesday, September 01, 1999 3:09 PM
> To: vxwork...@csg.lbl.gov
> Subject: symbols, searching in vxworks
>
> Submitted-by: r...@DynRes.com
David H. Olson
Staff Engineer
Oresis Communications, Inc.
14670 NW Greenbrier Parkway
Beaverton, OR 97006
503.533.0717 x246 Fax:503.533.8223
dol...@oresis.com
Dave Olson
the target shell either, as you suggest via rlogin, or in the
form '@ld' from the host shell. (The '@' character causes
those commands implemented on both the host and the target
to be interpreted by the target. Other examples include
'ls', and 'pwd'.) Unlike the host version, the target shell
version of ld() also accepts a parameter that chooses whether
or not the ld() command will stop a script from executing if
there are undefined symbols in the downloaded object.
The disadvantages of this approach are:
- you must be running the target shell
- the download occurs in two steps. First the entire
object is copied into the target shell's memory; then
the linking and relocation occurs. You must have
room in your target memory for the entire module.
Certain module formats can be huge if the module is
compiled for debugging. A module of mine compiled for
the PowerPC, hence in ELF format, that represented
250K text+data was 10 Meg in size. After the download,
of course, that memory is available for your programs
use, except that you also have used some of your memory
to hold all the symbols whether you need them all or not.
- if you're also trying to use the host facilities such as
the host shell or debugger, you also need to have 'symbol
table synchronization' enabled in order for the host to
find out about the symbols in the module you downloaded.
This represents another task running on the target and
consuming target resources.
Prior to the introduction of Tornado, we had made extensive use
of the naturally available system symbol table. I've come to
the conclusion that Tornado has made use of this resource quite
difficult and no longer consider it available for programmatic
use.
David H. Olson
Staff Engineer
Oresis Communications, Inc.
14670 NW Greenbrier Parkway
Beaverton, OR 97006
503.533.0717 x246 Fax:503.533.8223
dol...@oresis.com
> -----Original Message-----
> From: Alexander_R...@res.raytheon.com
> [mailto:Alexander_R...@res.raytheon.com]
> Sent: Thursday, September 02, 1999 6:45 AM
> To: dol...@oresis.com; r...@DynRes.com
> Subject: RE: symbols, searching in vxworks
>
>
> Hello,
>
> When connecting to the target via rlogin using the "target
> shell", another
> version of "ld ( )"
> is used, which, I think, updates directly the symbol table,
> residing on the
> target.
> If such version of "ld ( )" is used to load the application and the
> application's task(s) is spawned
> from the target shell, then, I think, programmatically run
> symFindByName()
> will not rely on
> the 'symbol table synchronization' and will be quite robust.
>
> Regards,
> Alex Povolotsky
>
> ---------------------- Forwarded by Alexander R
> Povolotsky/RES/Raytheon/US
> on 09/02/99 09:32 AM ---------------------------
>
>
> vxwe...@lbl.gov (the vxWorks Users Group Exploder) on
> 09/01/99 08:12:36 PM
>
> To: vxwork...@csg.lbl.gov
> cc: (bcc: Alexander R Povolotsky/RES/Raytheon/US)
> Subject: RE: symbols, searching in vxworks
>
>
>
>
> Submitted-by owner-vxwexplo-process Wed Sep 1 17:12:30 1999
> Submitted-by: Dave Olson <dol...@oresis.com>
r...@dynres.com
on the target server. Which, in fact I had not done. But when I added this option
to the target server, I could no longer run tgtsvr without errors.
When I start up tgtsvr, I get the following error messages:
Fatal WTX error (0x10136), synchronization stopped
Fatal WTX error (0x1012f), synchronization stopped
Others have suggested that this effort might be futile. It may in fact be, but having
started down this track, I'd like to see it a little further along.
So, does anyone have any hints on what this message might mean?
My configuration of the OS includes:
include_net_sym_tbl
include_sym_tbl
include_sym_tbl_sync
> When you create your target server in Tornado make sure that you
> press ALL symbols and Target/Host symbol sync buttons in the middle
> of the create target server window.
VxWorks
Chris Hann
Content-Type: text/plain; charset="us-ascii"; format=flowed
>The disadvantages of this approach are:
> - you must be running the target shell
> - the download occurs in two steps. First the entire
> object is copied into the target shell's memory; then
> the linking and relocation occurs. You must have
> room in your target memory for the entire module.
> Certain module formats can be huge if the module is
> compiled for debugging.
Sorry to intrude.
This is only true if you are using a netdrv; if you use nfs or a local
drive of some sort, which supports standard disk operations, then the
loader will only extract those elements of the object file which it needs.
netdrv was designed to overlay access methods which cannot support standard
disk i/o operations such as seek, the file locally and then accessed almost
as a RAM drive.
Chris Hann
Wind River Systems
--=====================_132600529==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
<blockquote type=cite cite>The disadvantages of this approach are:<br>
- you must be running the target shell<br>
- the download occurs in two steps. First the entire<br>
object is copied into the target shell's memory;
then<br>
the linking and relocation occurs. You must
have<br>
room in your target memory for the entire
module.<br>
Certain module formats can be huge if the module
is<br>
compiled for debugging. </blockquote><br>
Sorry to intrude.<br>
<br>
This is only true if you are using a netdrv; if you use nfs or a local
drive of some sort, which supports standard disk operations, then the
loader will only extract those elements of the object file which it
needs. netdrv was designed to overlay access methods which cannot support
standard disk i/o operations such as seek, the file locally and then
accessed almost as a RAM drive.<br>
<br>
Chris Hann<br>
Wind River Systems<br>
</html>
--=====================_132600529==_.ALT--
Charlie Grames
Don't be discouraged from following your current path. What you are attempting
with symFindByName() not only works but works well for us. If you now have
symbol synchronization working, everything else should fall into place.
Let me set the record straight on a few points:
1) You do NOT need the target shell to load modules from the target or to run
"@ld" from the host. We have the target shell disabled for security reasons and
do loads from both the target and the host with no problem.
2) Loading from the target occurs in two steps ONLY if you are using the default
netDrv driver to load your files from a remote host. netDrv uses FTP or rsh to
load the entire file into target memory, after which the loader does its job
with the copy in memory. ANY time you open a file with netDrv, it loads the
entire file into memory; this is not peculiar to loading files from the target.
If you want to avoid this problem, use nfsDrv (refer to the Reference Manual)
instead. Of course, this assumes you are running NFS on your host.
3) The behavior of symbol tables in VxWorks from the perspective of the target
has not changed at all since pre-Tornado days. What HAS changed is that along
with the introduction of host tools came a separate host symbol table that, by
default, has nothing in common with the target version other than the symbols
defined by the VxWorks kernel itself. Symbol synchronization assures that both
tables remain the same regardless of what you do from either the target or the
host to change them.
I will admit that there can be drawbacks to symFindByName(): You have to
configure a target-based symbol table, which takes memory, and you have to
configure symbol synchronization to use host tools, which creates an additional
task (but only when the target server is active and symbol synchronization has
been requested). If you are creating a small embedded system, availability of
system resources may make this approach impractical. If, however, creating a
dynamic system is more important, using symFindByName() (and associated bits) is
invaluable.
With our systems, after we have reached a certain point in development, we
configure our targets to load applications automatically at startup and attach
host tools only when necessary. This assures that our applications run as close
as possible to the way they will when deployed while still allowing us access
with the host tools. It is a system that has worked quite well for us.
Good luck!
Charlie Grames
The Boeing Company
Charles.R.Grames @ boeing.com
P.S. Check out the routine symSyncTimeoutSet() in the Reference Manual. You
may find it useful if you are working with large programs.
r...@DynRes.com wrote:
> Right after I hit send on this message, I found what I was looking for on the
> Wind River support web site.
> In case anyone else is interested, this indicates that the WIND_REGISTRY
> environment variable has not been properly set (TSR 44169)