This is the mail archive of the
mailing list for the GCC project.
adding support for vxworks os variants
- From: Olivier Hainque <hainque at adacore dot com>
- To: gcc at gcc dot gnu dot org
- Cc: nathan at codesourcery dot com, Joel Brobecker <brobecker at adacore dot com>
- Date: Mon, 19 May 2014 15:41:16 +0200
- Subject: adding support for vxworks os variants
- Authentication-results: sourceware.org; auth=none
Here is a quick description of changes we would like to contribute to the
VxWorks ports, with a preliminary query to maintainers on what would be the
most appropriate form for such changes to be deemed acceptable:
On a few CPU families, variants of the VxWorks OS are available.
Typically, there is the base VxWorks 6 or AE (653) kernel & environment,
- a simulator (VxSim) on some targets,
- a "CERT" variant of the OS to address requirements specific to
safety certification standards
- a "MILS" variant of the OS to address requirements specific to
- an "SMP" variant of the OS for multiprocessor systems.
We (AdaCore) have been maintaining toolchains for a few of these variants
over the years, with integrated facilities allowing easier uses of the toolchain
directly from the command line.
For mils, the set of changes is significant enough to warrant a specific
triplet. I'll be posting the patches soon.
For the other variants, the need for separate triplets is less clear. Indeed,
what the changes do is essentially to control link time behavior, typically:
- for VXSIM or SMP, the crt files and libraries we need to link with are located
in a different directory
- for CERT, the system entry points available to the application are all
in a big object and we're not supposed to link in anything else by default
The WindRiver environment drives everything through a GUI and Makefiles. E.g.
for CERT, this explicitly links with -nostdlib to remove all the defaults, then
add what is really needed/allowed.
Working directly from the command line is often useful, and doing the correct
thing (getting rid of inappropriate defaults, figuring out the correct of -Ls,
...) is cumbersome.
For vxsim or smp, having entirely separate toolchains with different triplets
for so minor differences seemed overkill and impractical for users, so we have
added "-vxsim" and "-vxsmp" command line options to our toolchains to help.
We have done the same for the cert variants, with a "-vxcert" command line
option, but wonder if a separate triplet wouldn't actually be better in this
One small concern is that the system toolchains don't know about the new
options, and we think that it might be of interest to minimize the interface
Thanks in advance for your feedback,
With Kind Regards,