ANSI Multicore

From DDCIDeos
Jump to navigationJump to search

ANSI library updates for Desert_Eagle_Program.

A DAL A project.

This page tracks development and verification activities and progress.

Deos_Desert_Eagle_D2_Release is unverified.

The final release will be verified (at least for ARM).


Scope

The project calls for ANSI to be extended with the following APIs for Deos_Desert_Eagle_D2_Release:

  • localeconv()
  • setlocale()
  • printf() & vprintf()

The following APIs may be added to another component:

  • calloc() & malloc()
  • gmtime() & gmtime_r()

C++ Runtime Library Support for new & delete should be added to the same component as calloc() & malloc():

  • _ZdaPv & _ZdlPv
  • _ZdaPvRKSt9nothrow_t
  • _ZdlPvRKSt9nothrow_t
  • _Znaj & _Znwj
  • _ZnajRKSt9nothrow_t
  • _ZnwjRKSt9nothrow_t

The following C++ Runtime Library Support may be added to another component:

  • __dso_handle
  • C++ casting support, except for dynamic cast


Design Notes

C/C++ Runtime Library Support

Define symbol __dso_handle that GCC may reference. The value held in this object may tie in with thread local storage for SOs (other areas that appear to use a SO specific index is atexit()). If separate values must be available for each SO then the definition probably needs to go into the startup library. It is unknown if Desert Eagle requires particular values or only the symbol definition.

C++ Casts

From an email from RLF: C++ casts are static_cast, const_cast, reinterpret_cast, and dynamic_cast, so the first 3 are needed. If all of these are handled by GCC without a support function then we're done. I guess a question is should we have some level of test for this so a future compiler upgrade, architecture port, etc ensures this has not changed. If not in a high DAL component ensuring an example uses each type of cast could be sufficient that we don't have a missing function.

The details of C++ casts are explained by http://www.cplusplus.com/doc/oldtutorial/typecasting/ (for those - like me - that find the C++11 standard 5.2.7 - 5.2.11 really difficult to understand). It explains how all static_cast, const_cast and reinterpret_casts can also be done using a C style cast while only dynamic_cast involves extra runtime checks. The task is thus to ensure Deos supports all C casts which we have claimed for a long time.

C++ Runtime Library Support

GCC uses eight runtime functions to implement the C++ new and delete operators (new & delete, single & array, with/without throw). Given ordinary C heap functions (malloc, calloc, free), very few lines should be needed for allocation and deallocation.

The runtime functions that actually throw (_Znaj, _Znwj) present a couple of challenges:

  • The Deos code check list prohibits Deos libraries from using linguistic exceptions.
  • Deos provides no mechanism for throwing a C++ exception.
  • This project does not specify support for C++ exception handlers so the effect to a throw will be to terminate the thread.

Decision: The throw variants will not actually throw. Instead they will raise a Deos exception (in a loop).

Decision: The delete functions will be no-ops (C free is not required and its absence simplifies malloc).

Undecided: Should this C++ compiler support live in a C++ specific compiler support SO or should it be added to GCC startup (libgcc-so)? Note that C++ new will call malloc() and that the containing SO thus must link against ANSI.

Heap

The basic malloc() can allocate memory in several ways. The registry could hold a maximum process allocation that the ANSI initialization could allocate once and for all so that a simple high-water mark (in the absence of free()) would suffice. Pages could be allocated from the kernel as needed which would conserve memory but this requires non-trivial synchronization with the kernel. If free() must be provided (at least for C++ delete) then maintenance of a free list is necessary and fragmentation becomes an issue.

No-one likes holding the desired heap size in a new registry. Another possibility is an environment variable with a particular name whose value if defined would determine the desired heap size. Further thinking about how to tell malloc() the desired heap size suggests that the environment variable probably is also undesirable. It would be problematic for dynamically created processes to be started with such a heap setting; the creator would need to learn to set up the environment variable and would need a new way to determine the value.

Decision: Pages will not be pre-allocated. Malloc will allocate pages from the kernel using get/setNextLibraryAddress and virtAllocDEOS as necessary; some simple strategy will e.g. allocate small sizes out of a shared page and larger sizes (at least > 1 page) directly from the kernel. This way, heap pages are only allocated as needed and they will come out of the virtual pages reserved for the process.

Limitation: Right now there is no way for ANSI to make get/setNextLibraryAddress MT-safe.

Locale

No detailed requirements are present in the SoW beyond the APIs themselves. Minimal work is to provide only what little the C standard requires.

Customer response: Unless hosted applications are expecting regional support, default C program locale “C” might be reasonable. The “C” locale is neutral and allows programs to be more predictable.

Decision: Stick with the minimal implementation until customer reports specific needs beyond that.

Printf

The proposed solution has the expected printf() & vprintf() APIs. Internally they are small wrappers of _printer() (like sprintf etc.). Each character is output as the formattting progresses by calling a user provided function to handle a single character. Until a user function is provided, output is discarded (as if written to a nul device). The way to set up the user provided function is through a Deos specific API __set_putchar (the name is intended to refer to the C function putchar that works as the user function must).

There are two problems with this proposal:

  • It will be difficult to call __set_putchar early enough to get output from static initializers.
  • The user code must be modified and recompiled.

Other proposals:

  • Define environment variable to be looked up by ANSI during loading to determine the output function. Somewhat clumsy and problems getting the environment variable set up for dynamically started processes. Rejected.
  • ANSI depends on special SO which the user can replace. This forces all processes to run with the same output function. Rejected.

Decision: The __set_putchar is the way to provide the output function for now. We anticipate that the kernel/loader's resolution of weak symbols will be improved; if so, then a special function name will be defined and ANSI will use a weak reference to it.

Time

From an email from JON: There is a lot of history affecting the definition of time_t (down to C not having unsigned types until circa 1978). POSIX requires it to be some integer type as opposed to a float type - which we are happy to comply with. Most environments have used a signed integer type; this makes differences between two time_t values meaningful (as in T1 - T2 < 0 => T2 - T1 > 0). Typical 32 bit environments define time_t as a 32 bit type which limits the range to 2038 or 2106 (depending on signedness); typical 64 bit environments define time_t as a signed 64 bit type which can represent seconds until the Sun burns out and allows representation of points in time before the C epoch. Again the ARM ABI specifies a precise definition: unsigned int. My recommendation is for Deos to not provide compatibility with older 32 bit operating systems and define time_t as int64_t for all architectures so that no year range restrictions exist. A potential problem with this is that compilers for 32 bit architectures may implement some 64 bit calculations by calling support functions (which Deos may not provide at present).

Decision: The Y2038 problem must be avoided; signed 32 bit time_t is out. RTEMS 5.0.3 defines time_t as either long or __int_least64_t for all of arm, ppc and x86 (based on a preprocessor symbol); the 64 bit possibility is new in 5.0.3 but is the one to use for compatibility with Deos ANSI. Deos ANSI always uses a 64 bit signed int for time_t.

Undecided: Right now, gmtime is placed in ANSI. There is a revived interest in additional time functions (asctime, ctime, localtime). If these happen in the time frame of this project should the time functions together still be in ANSI?

Activities

Outstanding Questions to Customer

  • We intend to avoid the Y2038 problem using a 64 bit time in spite of ARM ABI.
  • We intend to support printf() and vprintf() with a user action to handle each character.
  • We need to understand which locales to support in localeconv() and setlocale().
  • Are C++ delete operations expected to free resources or be no-ops?
  • ALL DONE

Outstanding Requirement Tasks

  • ALL DONE

Outstanding Code Tasks

  • Initial implementations of APIs localeconv(), setlocale(), printf() & vprintf() have been added to ANSI.
  • Initial implementations of APIs gmtime() and gmtime_r() have been added to ANSI.
  • Implement malloc().
  • Implement C++ new and delete support. See Design Notes.
  • Determine what runtime support could be needed for C++ casting support.
  • ALL DONE

Outstanding Test Tasks

  • Develop new test cases
  • Develop preliminary test procedures and complete
  • ALL DONE


Task
Assignment
Status
Requirements Development JON Done
Standards Change Analysis JON Done
Architecture Change Impact Analysis JON Done
Initialize Status Files JON Done
Requirements review TBR Done
Code Development, i.e. trace tag insertion and additional test points as determined via test development. JON Done
Code review TBR Done
Test Case Development MAS Done
Test Procedure Development MAS Done
Test Reviews DED Done
Software life cycle audits JEC Done
ABC SCAT Qual JON Done
Before the following can be done the above activities must be complete
Integration Review JON Done
Before the following can be done the Requirements Coverage analysis' traceability needs to be confirmed and SCAT Qual need to be completed
Formal build (including Conformity inspection) JEC/JON Done
Before the following can be done the Formal build needs to be completed. Each executable object code analysis has an analysis and review task.
Executable Object Code Analysis (Testing vs Release variant equivalence)
Executable Object Code Analysis Review (Testing vs Release variant equivalence)
Requirements Coverage Analysis JON Done
Before the following can be completed all of the above analysis need to be completed. The RFS was completed with the expectation the analysis above will be successful.
Run For Score JON Done
Test Results Review JON Done
Before the following can be done the Run For Score needs to be completed
Structural coverage analysis JON Done
Verification audit JEC Done
Before the following can be completed all of the above tasks need to be completed
Floating-point Analysis JON Done
Report Documents
- SLCECI JON Done
- SLCECI review TBR Done
- SCI JON Done
- SCI review TBR Done
- Open Problem Reports List JON Done
- SAS JON Done
- SAS review TBR Done
Populate the cert archive JON Done
Software conformity audit JEC Done
Retrieved from "https://ddci.zapto.org/ddciWiki/index.php?title=ANSI_Multicore&oldid=38338"