vxworks 6.x GNU problem
blue
We have our own BSP. We created a VxWorks image project which is based
on our BSP for our target.
When we use DIAB as TOOL for our BSP and VxWorks image project, our
target boots successfully. But when we use GNU as TOOL for our BSP and
VxWorks image project, the target does not boot and we see the
following logs on the console:
Host Name: bootHost
Target Name: vxTarget
User: target
Attaching interface lo0... done
alignment
Exception current instruction address: 0x00000008
Machine Status Register: 0x0000b032
Data Access Register: 0xffffffc7
Condition Register: 0x20000482
Data storage interrupt Register: 0x00002211
Task: 0x1ffed30 "tRootTask"
0x1ffed30 (tRootTask): task 0x1ffed30 has had a failure and has been
stopped.
0x1ffed30 (tRootTask): fatal kernel task-level exception!
When we use DIAB and the target boots successfuly the logs are a
follows:
Host Name: bootHost
Target Name: vxTarget
User: target
Attaching interface lo0... done
Attached IPv4 interface to motfcc unit 0
VxWorks
Copyright 1984-2006 Wind River Systems, Inc.
CPU: 8280
Runtime Name: VxWorks
Runtime Version: 6.4
BSP version: 2.0/9
Created: Nov 6 2008, 10:44:35
ED&R Policy Mode: Deployed
WDB Comm Type: WDB_COMM_END
WDB: Ready.
- What should we do to use GNU as TOOL and boot MPC8280 successfully?
- Are there any points that we should take into account when we use
GNU as TOOL?
- Are there any points that we should take into account when we use
DIAB as TOOL?
- Is the problem caused by the fact that vxWorks libraries are built
with DIAB compiler, and our projects are built with GNU compiler?
nois...@gmail.com
No, it's not caused by that.
GCC sometimes optimizes more aggressively than Diab, depending on what
compiler options you use. However, this is not a problem, per-se: it
just means that Diab will sometimes "correctly" compile code which is
subtly broken while the same code compiled with GCC will yield a
runtime error. One common problem is forgetting to make appropriate
use of the volatile keyword: this can break device driver code in
particular, because the compiler might re-order instructions to make
the code execute faster without realizing that the underlying hardware
requires things to be done in a specific sequence (i.e. reading/
writing registers to initialize a device).
Sometimes the issue is not related to optimization, but simply due to
the two compilers generating slightly different assembly output. For
example, you may have a subtle stack corruption bug in your code, but
the bug might happen to not trigger a runtime failure when you build
the code with Diab because it lays automatic variables out in the
stack a little differently than GCC.
The exception output indicates a branch through a NULL pointer (PC ==
0x00000008). You really need to sit down and debug this thoroughly.
Do _NOT_ just say "well, it works with Diab so it must be okay." It is
not okay: the problem is very likely a bug in your BSP code somewhere,
and the fact that Diab is letting you get away with having that bug
there is a bad thing, not a good thing. If the code is correct, it
should build and run equally well with either compiler.
Unfortunately, debugging this problem may be tricky (unless you have
the WInd River Probe or ICE). This is because the crash occurs before
the target shell is spawned. One suggestion I can give you is to build
vxWorks.st instead of vxWorks:
% cd target/config/myBsp
% make clean
% make TOOL=GNU vxWorks.st
One difference between the two is that vxWorks.st does not
automatically start networking: the kernel boots and the target shell
is started, but network initialization is defered. You can start
network manually from the shell once the target has booted:
-> sp usrNetInit
This will spawn a task that runs usrNetInit(), which will complete
network initialization. Assuming the bug still occurs, you will again
get an exception, but this time it will be in the new task (t1). You
can now use the target shell to get a backtrace:
-> tt t1
This hopefuily will help you track down which function branched
through the NULL pointer so that you can isolate the buggy code.
-Bill