Please help - Undefined Symbol !

[Huynh, Hong [CAR:9N23:EXCH]]

Tornado 2.0
VxWorks 5.4
BSP: PcPentium (466 MHz Celeron)

Hi All: I have problem loading the application on to the target hard drive.
It is OK when I do this remotely through a Tornado Shell (everything runs
fine including spawning the function!). But, when do this on the target
itself (target has vxworks image and the application), below is what I got.
Can anyone tell me what is wrong? I understand that the symbol is somehow
missing/undefined but how to get this problem fixed? Any help or pointers
would be greatly appreciated?

-> ld <router
value = 134204756 = 0x7ffcd54 = bgpNode + 0x310
-> kernelTimeSlice(1)
value = 0 = 0x0
-> sp ace_main
undefined symbol: ace_main
-> lkup "ace_main"
ace_main(unsigned int) 0x07cbd934 text (router)
global constructors keyed to ace_main(unsigned int) 0x07cc0c80 text (router)
global destructors keyed to ace_main(unsigned int) 0x07cc0c48 text (router)
value = 0 = 0x0

Thanks

Hong

[DrDiags]

Hong,

You should enable synchronizing the Host and Target Symbol Tables option in
your Kernel. And make sure that symbol table syncrhonization is enable in the
Target Server configuration. Why you should have to do this is better explained
by more learned VxWorks users than myself. A lot of this was to alleviate
resource demands on the target, but try these suggestions. The flip side of this
problem is that if you load your symbols through the target shell (not WindSh),
crosswind will not be able to locate/debug the newly added symbols since I
believe it uses the symbol table on the Host. HTH

[dde...@my-deja.com]

A possibility is that you ace_main is a munged C++ symbol. If it is
compiled in a .cpp file and is now given C linkage (extern "C") that
could be the case. Then it is possible that the shell doesn't know how
to decode C++ munged names. Try preceeding the definition of ace_main
with extern "C" if this sounds like it could be the problem:

extern "C" int ace_main(unsigned int)
{
... code here...
}

Then recompile, relink and see if you can spawn a task using ace_main.

Hope this helps.

-- Don

In article <90s5jv$ia3$1...@bcarh8ab.ca.nortel.com>,

Sent via Deja.com http://www.deja.com/
Before you buy.

[Dave Korn]

>In article <90s5jv$ia3$1...@bcarh8ab.ca.nortel.com>,
> "Huynh, Hong [CAR:9N23:EXCH]" <ho...@americasm01.nt.com> wrote:
>> -> ld <router
>> value = 134204756 = 0x7ffcd54 = bgpNode + 0x310
>> -> kernelTimeSlice(1)
>> value = 0 = 0x0
>> -> sp ace_main
>> undefined symbol: ace_main
>> -> lkup "ace_main"
>> ace_main(unsigned int) 0x07cbd934 text (router)
>> global constructors keyed to ace_main(unsigned int) 0x07cc0c80 text
>(router)
>> global destructors keyed to ace_main(unsigned int) 0x07cc0c48 text
>(router)
>> value = 0 = 0x0

dde...@my-deja.com wrote in message <912h52$43a$1...@nnrp1.deja.com>...

>A possibility is that you ace_main is a munged C++ symbol. If it is
>compiled in a .cpp file and is now given C linkage (extern "C") that
>could be the case. Then it is possible that the shell doesn't know how
>to decode C++ munged names. Try preceeding the definition of ace_main
>with extern "C" if this sounds like it could be the problem:
>
>extern "C" int ace_main(unsigned int)
>{
> ... code here...
>}
>
>Then recompile, relink and see if you can spawn a task using ace_main.

Or alternatively, type "sp ace_main" and then press Ctrl+D to add
the signature to the end of the mangled C++ name before you press
enter. Ctrl+D completes any partially typed symbol, and is *very*
useful when you need to refer to mangled C++ names from the
command shell.

DaveK
--
They laughed at Galileo. They laughed at Copernicus. They laughed at
Columbus. But remember, they also laughed at Bozo the Clown.

[mmchugh]

Another alternative is to type "sysCplusEnable=1" in the target shell.
That allows the shell to automatically demangle the names. You can
configure vxWorks to turn sysCplusEnable on automatically or you can
just externally reference it in your code and set it to 1 so you don't
have to type it every time.

M.McHugh