testsuite & Tornado (continued)

[sxthree at penfeld dot tls dot mms dot fr (SXTHREE)]

Hi

I stil haven't run the testsuite but I can issue a few notes
about the process. Hey Mike, running the testsuite is quite 
a hard work !

-> DejaGnu does not make a difference between VxWorks versions.
Until 5.2, something like, tip, telnet or rlogin was used to
communicate with the target. Since 5.3 (Tornado) we use windsh
which is more user friendly but does not exactly reflect what's
happening on the board. The shells behave differently and
cannot be handled the same way by DejaGnu.

-> DejaGnu reboots the board between tests. It takes about 2
minutes to load the BSP onto the board. It's not very reasonable
to spend years for testing the compiler.

-> tests are real programs (with a main). If the program uses
arguments (argc, argv), those arguments must be provided in
the way we expect we will find them. I mean that VxWorks does
not recognize "main" as being a special function. Generally
something like crtbegin handles these parameters for you. We
do not use any crtxxxx on VxWorks. Manually generating the 
parameters is not so easy when you can't pre-suppose how many
they'll be.

-> Tornado uses a specific mechanism for handling global ctors/dtors.
As I said before, we're not using crtxxx so whatever collect2 may
do, we still have to make an additional pass to retrieve the
global ctors/dtors from the object before loading it. This pass
is called "munching" and its purpose is to generate a C file
containing structures with pointers to _GLOBAL_c/dtors functions.
Of course, the tool provided by WindRiver cannot be used directly
with programs compiled by egcs because of the mangling change. The
problem is that global c/dtor functions now contain '.' where they
used to contain '$' with the old mangling scheme and there is no
way to handle points in identifiers in C. I solved the problem
by issuing sed commands:
> xxxx-nm foo | munch > ctdt1.c
> cat ctdt1.c | sed -e 's/\./$/g' > ctdt2.c
> xxxx-gcc flags -fdollars-in-identifiers -S -o ctdt2.s ctdt2.c
> cat ctdt2.s | sed -e 's/\$/./g' > ctdt.s
> xxxx-gcc -c -o ctdt.o ctdt.s
...
A better way to do all this stuff would be to directly generate
the assembly code but that won't be portable.
DejaGnu may want to automate this process for C++ tests.

Well, all the above are mainly DejaGnu issues but I'm not on their
maillist. 
I'm amazed I've never seen any message on the egcs list concerning
test results for embedded platforms. I cannot believe I'm the first
to try this kind of things...

-- later

Nyny