symFindbyName() problem

[Roy Gordon]

We are working using C++ and vxSim 5.3.

symFindbyName() isn't returning the address of functions whether or not
we pass in the mangled or demangled name (we've tried all combinations).

The vxWorks shell recognizes the name (mangled) and we can in fact
breakpoint there.

Here's are call:

rv = symFindByName(sysSymTbl, name, (char **)&entryPt, &pType);
if (rv == ERROR) {


The name in question is:

ifnsSvr

and the mangled name, according to nm, is:

ifnsSvr__FiPPc

But, we tried setting 'name' to:

ifnsSvr
_ifnsSvr
ifnsSvr__FiPPc
_ifnsSvr__FiPPc

and none work. (We tried prepending an '_' because we were told that
internally all symbols begin with an underbar.

The symbol is clearly there (as can be seen in the shell, and gdb) but we
can't seem to find it using symFindByName(). We load all our executables
prior to running any tasks.

Any ideas, advice, etc.?

TIA.

-- roy

Someone told us that there are C++->C name conversion functions and we
should use those before calling symFindByName(). But we haven't been
able to find them? Have we just been blind to it?

91: nm ifnsSvr | egrep ifnsSvr
ifnsSvr:
[15] | 0| 0|FILE |LOCL |0 |ABS |ifnsSvr.cc
[3047] | 0| 664|FUNC |GLOB |0 |1 |ifnsSvr__FiPPc

[Jeremy Frank]

hi,

Roy Gordon wrote:
>
> We are working using C++ and vxSim 5.3.
>
> symFindbyName() isn't returning the address of functions whether or not
> we pass in the mangled or demangled name (we've tried all combinations).
>
> The vxWorks shell recognizes the name (mangled) and we can in fact
> breakpoint there.

I must ask:
-- Does your target have a symbol table? Often with vxworks 5.3, the
target does not have a symbol table, since Tornado can take care of
symbol lookups. (I have not used vxsim5.3, so I have no experience
about how they configured it.) The options are: no symbol table, load
symbol table at startup, or standalone symbol table.
-- Is the "vxWorks shell" you mention part of Tornado? Target-resident
shells rely on a target-resident symbols table, whereas Tornado shells
rely on the Tornado host-resident symbols table.

I am guessing that perhaps you have no target-resident symbol table
(which saves you many MB of ram!), so any target-based calls to
symFindByName will fail, and that you are using the Tornado shell, which
is using its own host-based symbol lookup. I really wish Tornado had
been designed to make it clear what commands run on the host and what
commands run on the target.

> Someone told us that there are C++->C name conversion functions and we
> should use those before calling symFindByName(). But we haven't been
> able to find them? Have we just been blind to it?

Yes, there is such a beast. No, you are not blind. It is simply one of
the many "private" features of vxworks (WRS: Why oh why is this
private?)! It is called cplusDemangle(). Check out
/tornado/target/h/private/cplusLibP.h. I do not know whether the symbol
table would contain the mangled or unmangled name.

--jsf

[Stan Schneider]

>> Submitted-by rgo...@net.com Mon Jan 13 14:29:03 1997

>> We are working using C++ and vxSim 5.3.
>>
>> symFindbyName() isn't returning the address of functions whether or not
>> we pass in the mangled or demangled name (we've tried all combinations).

Are you using the target-resident symbol table? If not, then winsh & crosswind
will find the symbol just fine, but symFindByName doesn't really exist; it's a
stub to a routine that returns an error. Tornado does this to save target
memory---symbol tables get big. There are many workarounds to this, including
a free syncronization script that Leonid posted some time back (so both host &
target symbol tables match), and a host-based "target-server server" included
with our RTILib product (so the target can use the host-based table).

Hope this helps,

-- Stan