This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

adding support for vxworks os variants


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,
then also:

- 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
  security standards
- 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

Thoughts ?

Thanks in advance for your feedback,

With Kind Regards,


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]