Hello Godmar, This is a very difficult question to answer as it will depend a lot on the constraints of the OP-TEE environment and what subset of the C++ language and libraries that the developers are willing to support. I can speak a little bit about generic support of C++ in embedded systems via my experience with ARM's commercial toolchain, which is based on a mixture of clang, libc++, libc++abi and libunwind; and ARM's own C-library and linker. This isn't going to directly map to the GNU world but I don't think it will be too far off.
The minimal additional support for C++ over C is support for the language runtime, representing helper functions that the compiler expects to be defined, regardless of whether these are called in the source code; for example the various forms of new and delete. These functions often have a cxa prefix are defined generically by the Itanium C++ ABI and built upon by platform specific ABIs such the ARM C++. In the llvm world these are defined by the libc++abi library with stack unwinding provided by the libunwind library. In general I wouldn't expect there to be any major difficulty in providing such a run-time support library for OP-TEE, but I don't know anything at all about any special restrictions that platform has that might get in the way. For example I don't know whether OP-TEE requires additional libraries to be certified? Any use of C++ static constructors need to be initialised by the run-time environment, this is typically handled by the C-library start-up. Support for the C++ standard library is more complicated, particular with C++11 and beyond. There are some areas of functionality that are fairly easy to say this won't work on our platform. For example std::thread may not work if the underlying platform has no support for threads. There are some areas such as the containers and algorithms that will require little additional support beyond the runtime. Some features such as use of iostream will significantly bloat the code as this will pull in all the locale support, require static initialisation of the cin, cout objects. Perhaps the most difficult decision is whether to support exceptions. For your own code, choosing not to support exceptions isn't a problem as both gcc and clang can compile without exception tables, however many C++ libraries, including the standard library make use of exceptions, and an uncaught exception results in program termination. The libc++ library can be compiled without exceptions but this just means it will terminate the program if an exception would be thrown. To summarise, if the platform runtime support is limited, there isn't an easy answer to say C++ is supported, and the answer heavily depends on the design choices of the platform holder. The OP-TEE developers would most likely have to define a subset that is supported and constantly monitor it as toolchains change. They may not consider this worth the trade-off against the simpler answer of C++ is not supported. Hope this is of some use Peter On 11 August 2017 at 14:53, Godmar Back <god...@gmail.com> wrote: > In a recent github thread > <https://github.com/OP-TEE/optee_os/issues/1708#issuecomment-320245973> it > was suggested that I ask this list about what the exact reasons for the > lack of C++ support are, and how/if they break down by C++ feature so as to > gauge a possible investment in remedying this situation at least partially. > > In other words, suppose I changed the build process to include libstdc++, > libgcc, and libgcc_eh (and/or other runtime support commonly linked with > C++ programs), what features of C++ would work/still fail? And what > implementation work would be required to implement the missing features? > On a related note, are there intrinsic properties of the secure environment > that may conflict with running C++ code, if any? > > Thank you. > > - Godmar > _______________________________________________ > linaro-toolchain mailing list > linaro-toolchain@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/linaro-toolchain _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
