Hello, 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 case. 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 differences. Thoughts ? Thanks in advance for your feedback, With Kind Regards, Olivier
