Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Loading cpp program for VxWorks 6.x

784 views
Skip to first unread message

KB

unread,
Feb 24, 2009, 9:13:38 AM2/24/09
to
Hi,

My program consists of several libraries, e.g.: libComponent1.o,
libComponent2.o, libComponent3.o.
There are dependencies between them:
- libComponent1.o uses libComponent2.o
- libComponent2.o uses libComponent3.o
And finally I've got another library that uses all of those libraries and
contains the C++ main function: libMain.o

So far I've loaded them in the following way:
-> ld < libComponent3.o
-> ld < libComponent2.o
-> ld < libComponent1.o
-> ld < libMain.o
-> sp main

However, I find it not user friendly. I have to load all of the libraries in
the given order and I have to remember that order. I would like to load only
libMain.o and it would be able to load all of the remaining libraries
automatically, that are libMain.o dependencies.
E.g.:
-> ld < libMain.o
-> sp main

Currently the abovementioned two lines are producing me an error: undefined
references or symbols.
Could you give me a hint how to load C++ programs correctly, or perhaps
build them in the proper way?

Regards,
KB


PAD

unread,
Feb 24, 2009, 1:20:32 PM2/24/09
to
Hello,

Why don't you link all your modules together? This way you'd load only
one module from the shell's prompt.

Alternatively you right a little piece of code, say startMyApp.o, that
will load the application's modules (using the object module loader's
API) in the appropriate order for you. You can either link
startMyApp.o with your VxWorks image or load it from the shell's
prompt.

Note that the only officially supported way of loading C++
applications in VxWorks is to link all the modules together, then
munch this module to get a .out module with the appropriate
constructor and destructor calls setup.

Hope this helps,

--
PAD

KB

unread,
Feb 25, 2009, 3:18:09 AM2/25/09
to
> Why don't you link all your modules together? This way you'd load only
> one module from the shell's prompt.

My first approach was to link all of those libraries together and then munch
this. However, when I was trying to load such module I was getting an error:

-> ld < MyApp.o
ld(): error loading file (errno=0xe0009).
value = 0 = 0x0
->

When I load separate libraries everything works except the fact that it is
not elegant and not officially supported.

Have you met the abovementioned loading error? Perhaps I'm missing something
in linking all libraries together and munching them.
I've found out that the error means: S_loadLib_MISSING_SYMBOL_TABLE.
However, I still don't know how to deal with it.
Could you give me a hint?

Regards,
KB


PAD

unread,
Feb 25, 2009, 5:59:27 PM2/25/09
to
This errno means that your ELF file is missing the symbol table
section... This is weird. You can verify this with readelf: readelf -e
MyApp.o. You should see a section named ".symtab". If no such section
exists I'd say that the munching step messed up your file but I don't
know why this would happen. If you do see a ".symtab" section check
whether it is of the type SYMTAB and that its size is non null.

Just to be on the safe side: working with C++ modules is described in
a dedicated chapter of the VxWorks Kernel Programmer's Guide. Did you
make sure you followed the steps as described?

--
PAD

KB

unread,
Feb 26, 2009, 7:21:36 AM2/26/09
to
I went through all the chapters regarding C++ development for VxWorks.
I have used readelfppc command to check if there is ".symtab". I came into
the following conclusions:

1) ".symtab" is always present in my "out" files.
2) If my application is smaller than 65535 symbols (i.e. ".symtab"
position number is below that that value) everything is correct.
However, due to the fact that my program can become bigger I can easily
produce "out" file which also contains ".symtab" but the position number is
greater than 65535.
In such the case I can observe that my program has one more ".symtab" entry
which is ".symtab_shndx".
Moreover ".symtab_shndx" has link to ".symtab".
Please compare those 2 situations below and please note that there is
additional ".symtab_shndx" entry in the second case:

(LESS THAN 65535 symbols)

[1160]user@host:~/$ readelfppc -e MyAppl_case1.out | tail -n 4
[65229] .bss._ZNSt9_Facet NOBITS 00000000 1182078 000004 00 WAG
0 0 4
[65230] .shstrtab STRTAB 00000000 1182078 24c95c 00
0 0 1
[65231] .symtab SYMTAB 00000000 1e58920 15c610 10
65232 50904 4
[65232] .strtab STRTAB 00000000 1fb4f30 2f0f15 00
0 0 1
[1161]user@host:~/$

(MORE THAN 65535 symbols)

[1178]user@host:~/$ readelfppc -e MyAppl_case2.out | tail -n 4
[65567] .shstrtab STRTAB 00000000 118e708 24d0d7 00
0 0 1
[65568] .symtab SYMTAB 00000000 1e6bf70 15cfb0 10
65570 50976 4
[65569] .symtab_shndx SYMTAB SECTION 00000000 1fc8f20 0573ec 04
65568 0 4
[65570] .strtab STRTAB 00000000 202030c 2f23cc 00
0 0 1
[1179]user@host:~/$

3) Whenever I exceed 65535 symbols I am getting the mentioned error:
S_loadLib_MISSING_SYMBOL_TABLE.
-> ld < MyAppl_case2.out
ld(): error loading file (errno = 0xe0009).


value = 0 = 0x0
->

* Could you give me a hint how could we resolve this problem and load "out"
files bigger than 65535 symbols ?
* Should I change anything in my kernel configuration ?
* Is ".symtab_shndx" some kind of extension of ".symtab" when there is more
symbols than 65535 ?

Regards,
KB


PAD

unread,
Feb 26, 2009, 12:19:28 PM2/26/09
to
Hello KB,

Well, that your problem just there: the ELF format encodes the number
of sections in the file using a short integer. So you can't have more
than 65536 sections (including the special section 0) in a regular ELF
file. It appears that you somehow do have more than this number of
sections so I would guess that there is some kind of compiler-specific
extension at play here (possibly with one of the sections describing
additional sections).

From memory (I worked on it) the VxWorks loader does not support any
special tricks like this. What I think is happening is that since the
symbol table section order numbers are beyond the 65536 boundary the
loader simply does not find its header in the regular section header
table and so considers that there is no symbol table in the file.

I guess you are stuck with loading those modules individually then...

--
PAD

KB

unread,
Feb 26, 2009, 3:18:36 PM2/26/09
to
> I guess you are stuck with loading those modules individually then...

Unfortunatelly...
Thanks for your time and help.

Regards,
KB

KB

unread,
Feb 27, 2009, 7:43:34 AM2/27/09
to
Hi,

I've prepared a very simple C++ source code (see listing below) which
produces that error. If you have any idea how to load it please let me know.

After instantiating 170 different vector types the application is being
loaded correctly and the ELF table is smaller than
65535 elements.

user@host:~/$ readelfppc -e MyNewTest_170vecs.out | tail -n 10
[65168] .rela.debug_frame RELA 00000000 93d030 000318 0c
65170 65167 4
[65169] .shstrtab STRTAB 00000000 3eb058 1612fd 00 0
0 1
[65170] .symtab SYMTAB 00000000 93d348 110530 10
65171 46436 4
[65171] .strtab STRTAB 00000000 a4d878 128b3d 00 0
0 1
...
user@host:~/$

-> ld < MyNewTest.out
value = 25889928 = 0x18b0c88
-> sp main
Task spawned: id = 0x27c6180, name = t2
value = 41705856 = 0x27c6180
-> EXECUTED!

->

However when I have 171 vector types I exceed 65535 elements in ELF table
and fail in loading "out" file on my VxWorks.

user@host:~/$ readelfppc -e MyNewTest_171vecs.out | tail -n 10
[65807] .shstrtab STRTAB 00000000 3f0e4c 16348d 00 0
0 1
[65808] .symtab SYMTAB 00000000 94b184 111eb0 10
65810 46708 4
[65809] .symtab_shndx SYMTAB SECTION 00000000 a5d034 0447ac 04
65808 0 4
[65810] .strtab STRTAB 00000000 aa17e0 12a769 00 0
0 1
...
user@host:~/$

-> ld < MyNewTest.out


ld(): error loading file (errno = 0xe0009).
value = 0 = 0x0
->

I am using the following chain of commands to produce "out" file.

ccppc -mlongcall -msoft-float -I/WindRiver/vxworks-6.6/target/h -DCPU=PPC32
-DTOOL_FAMILY=gnu -DTOOL=sfgnu -D_WRS_KERNEL -o MyNewTest.o -c MyNewTest.cpp

nmppc MyNewTest.o | wtxtcl
/WindRiver/vxworks-6.6/host/resource/hutils/tcl/munch.tcl -c ppc > ctdt.c

ccppc -O2 -fstrength-reduce -fno-builtin -msoft-float -mstrict-align -fdollars-in-identifiers
-Wall -I/WindRiver/vxworks-6.6/target/h -I/WindRiver/vxworks-6.6/target/h/wrn/coreip
-DCPU=PPC32 -DTOOL_FAMILY=gnu -DTOOL=sfgnu -D_WRS_KERNEL -o ctdt.o -c
ctdt.c

ccppc -r -T /WindRiver/vxworks-6.6/target/h/tool/gnu/ldscripts/link.OUT -o
MyNewTest.out ctdt.o MyNewTest.o

Listing:

#include <string>
#include <iostream>
#include <map>
#include <vector>
#include <sstream>

template<int v>
struct Type
{
enum{value = v};
};

template class std::vector< Type<1> >;
template class std::vector< Type<2> >;
template class std::vector< Type<3> >;
template class std::vector< Type<4> >;
template class std::vector< Type<5> >;
template class std::vector< Type<6> >;
template class std::vector< Type<7> >;
template class std::vector< Type<8> >;
template class std::vector< Type<9> >;
template class std::vector< Type<10> >;
template class std::vector< Type<11> >;
template class std::vector< Type<12> >;
template class std::vector< Type<13> >;
template class std::vector< Type<14> >;
template class std::vector< Type<15> >;
template class std::vector< Type<16> >;
template class std::vector< Type<17> >;
template class std::vector< Type<18> >;
template class std::vector< Type<19> >;
template class std::vector< Type<20> >;
template class std::vector< Type<21> >;
template class std::vector< Type<22> >;
template class std::vector< Type<23> >;
template class std::vector< Type<24> >;
template class std::vector< Type<25> >;
template class std::vector< Type<26> >;
template class std::vector< Type<27> >;
template class std::vector< Type<28> >;
template class std::vector< Type<29> >;
template class std::vector< Type<30> >;
template class std::vector< Type<31> >;
template class std::vector< Type<32> >;
template class std::vector< Type<33> >;
template class std::vector< Type<34> >;
template class std::vector< Type<35> >;
template class std::vector< Type<36> >;
template class std::vector< Type<37> >;
template class std::vector< Type<38> >;
template class std::vector< Type<39> >;
template class std::vector< Type<40> >;
template class std::vector< Type<41> >;
template class std::vector< Type<42> >;
template class std::vector< Type<43> >;
template class std::vector< Type<44> >;
template class std::vector< Type<45> >;
template class std::vector< Type<46> >;
template class std::vector< Type<47> >;
template class std::vector< Type<48> >;
template class std::vector< Type<49> >;
template class std::vector< Type<50> >;
template class std::vector< Type<51> >;
template class std::vector< Type<52> >;
template class std::vector< Type<53> >;
template class std::vector< Type<54> >;
template class std::vector< Type<55> >;
template class std::vector< Type<56> >;
template class std::vector< Type<57> >;
template class std::vector< Type<58> >;
template class std::vector< Type<59> >;
template class std::vector< Type<60> >;
template class std::vector< Type<61> >;
template class std::vector< Type<62> >;
template class std::vector< Type<63> >;
template class std::vector< Type<64> >;
template class std::vector< Type<65> >;
template class std::vector< Type<66> >;
template class std::vector< Type<67> >;
template class std::vector< Type<68> >;
template class std::vector< Type<69> >;
template class std::vector< Type<70> >;
template class std::vector< Type<71> >;
template class std::vector< Type<72> >;
template class std::vector< Type<73> >;
template class std::vector< Type<74> >;
template class std::vector< Type<75> >;
template class std::vector< Type<76> >;
template class std::vector< Type<77> >;
template class std::vector< Type<78> >;
template class std::vector< Type<79> >;
template class std::vector< Type<80> >;
template class std::vector< Type<81> >;
template class std::vector< Type<82> >;
template class std::vector< Type<83> >;
template class std::vector< Type<84> >;
template class std::vector< Type<85> >;
template class std::vector< Type<86> >;
template class std::vector< Type<87> >;
template class std::vector< Type<88> >;
template class std::vector< Type<89> >;
template class std::vector< Type<90> >;
template class std::vector< Type<91> >;
template class std::vector< Type<92> >;
template class std::vector< Type<93> >;
template class std::vector< Type<94> >;
template class std::vector< Type<95> >;
template class std::vector< Type<96> >;
template class std::vector< Type<97> >;
template class std::vector< Type<98> >;
template class std::vector< Type<99> >;
template class std::vector< Type<100> >;
template class std::vector< Type<101> >;
template class std::vector< Type<102> >;
template class std::vector< Type<103> >;
template class std::vector< Type<104> >;
template class std::vector< Type<105> >;
template class std::vector< Type<106> >;
template class std::vector< Type<107> >;
template class std::vector< Type<108> >;
template class std::vector< Type<109> >;
template class std::vector< Type<110> >;
template class std::vector< Type<111> >;
template class std::vector< Type<112> >;
template class std::vector< Type<113> >;
template class std::vector< Type<114> >;
template class std::vector< Type<115> >;
template class std::vector< Type<116> >;
template class std::vector< Type<117> >;
template class std::vector< Type<118> >;
template class std::vector< Type<119> >;
template class std::vector< Type<120> >;
template class std::vector< Type<121> >;
template class std::vector< Type<122> >;
template class std::vector< Type<123> >;
template class std::vector< Type<124> >;
template class std::vector< Type<125> >;
template class std::vector< Type<126> >;
template class std::vector< Type<127> >;
template class std::vector< Type<128> >;
template class std::vector< Type<129> >;
template class std::vector< Type<130> >;
template class std::vector< Type<131> >;
template class std::vector< Type<132> >;
template class std::vector< Type<133> >;
template class std::vector< Type<134> >;
template class std::vector< Type<135> >;
template class std::vector< Type<136> >;
template class std::vector< Type<137> >;
template class std::vector< Type<138> >;
template class std::vector< Type<139> >;
template class std::vector< Type<140> >;
template class std::vector< Type<141> >;
template class std::vector< Type<142> >;
template class std::vector< Type<143> >;
template class std::vector< Type<144> >;
template class std::vector< Type<145> >;
template class std::vector< Type<146> >;
template class std::vector< Type<147> >;
template class std::vector< Type<148> >;
template class std::vector< Type<149> >;
template class std::vector< Type<150> >;
template class std::vector< Type<151> >;
template class std::vector< Type<152> >;
template class std::vector< Type<153> >;
template class std::vector< Type<154> >;
template class std::vector< Type<155> >;
template class std::vector< Type<156> >;
template class std::vector< Type<157> >;
template class std::vector< Type<158> >;
template class std::vector< Type<159> >;
template class std::vector< Type<160> >;
template class std::vector< Type<161> >;
template class std::vector< Type<162> >;
template class std::vector< Type<163> >;
template class std::vector< Type<164> >;
template class std::vector< Type<165> >;
template class std::vector< Type<166> >;
template class std::vector< Type<167> >;
template class std::vector< Type<168> >;
template class std::vector< Type<169> >;
template class std::vector< Type<170> >;
template class std::vector< Type<171> >;


int main() { std::cout << "EXECUTED!\n"; return 0; }


PAD

unread,
Mar 3, 2009, 2:34:07 PM3/3/09
to
Sorry, I don't know much about C++ so I can't help here. You probably
need to talk to WR support at this point.

--
PAD

KB

unread,
Mar 4, 2009, 9:00:46 AM3/4/09
to
> Sorry, I don't know much about C++ so I can't help here. You probably
> need to talk to WR support at this point.

No problem. Thank's for your attention anyway.

Regards,
KB


0 new messages