Build Process

• Introduction

• P.I.P.S. target types

• Symbol information

• Mapping POSIX handles to Symbian OS resource objects

  • Using non-system calls

  • Using the System Call Adaptation Layer

Symbian currently builds its emulator code with the Metrowerks CodeWarrior compiler (switching to Carbide around April 2007). This is known as the WINSCW build target. Binaries built with this compiler are put in the epoc32\release\winscw and epoc32\winscw directory trees.

You can build your programs for the emulator using Metrowerks CodeWarrior. The build tools also support the Microsoft® Visual Studio .NET 2003 and Microsoft Visual Studio v6 IDEs. For further information see the Build tools guide section of the Symbian OS Library. Note that licensees or third-parties may supply additional tools, or extend support to additional compilers, which are not described here.

The following sections describe the new Symbian OS target types introduced with P.I.P.S.. For further information see the native build targets section of the Symbian OS Library.

When using tool chains for pre-Symbian OS v9.3, the .mmp file has to be manually changed to link in various libraries.

For Symbian OS v9.3 onwards the tool chain supports the new STDEXE and STDDLL target types for P.I.P.S. EXEs and DLLs. See the Generation of STDEXE, STDDLL and STDLIB section for further explanation of the new target types introduced with P.I.P.S..

P.I.P.S. EXEs require adaptation logic to set up the C program environment and the P.I.P.S. run-time C library context - this is performed by the CRT0 library (also known as glue code, see the Glue code (CRT0) section for further details).

P.I.P.S. executables are implemented using native Symbian OS executables linked statically to the glue code. The new target types for P.I.P.S. include the glue code by default. The glue code provides the linking code between the E32Main() entry point and the main() entry point used in 'C' P.I.P.S. EXEs.

For further information see the Target Types section.

When building a P.I.P.S. DLL (that is, when the target type is STDDLL), function and data symbols with extern linkage will be exported or imported by default, without any requirement for IMPORT_C/EXPORT_C declarations in the header or source files.

Exporting of symbols with extern linkage is the assumed default on other platforms and enables the source code to be easily ported. Although this may normally be undesirable in the embedded world, it is supported for STDDLL to avoid portable source code having to include excessive decoration (that is, the IMPORT_C/EXPORT_C macros) for the Symbian OS platform.

STDEXE and STDDLL provide symbol name information. For more information on the new Symbian OS target types see the Generation of STDEXE, STDDLL and STDLIB section.

Several P.I.P.S. APIs that directly manipulate Symbian OS (native) resources are implemented in the System Call Adaptation Layer (SCAL). The exceptions to this are pthreads, and memory maps. The pthread APIs use RThreads and RMutexes directly from within libpthread. Similarly, RChunks that are used to provide support for memory maps are directly manipulated from within libc. Note that none of these APIs allow direct access to the underlying native resources. References to these are wrapped in POSIX-defined data structures. These data structures are intended to be treated as opaque and no attempt must be made to dereference or use the underlying resource reference directly.

All IPC calls enter the SCAL, but are handled in a separate IPC library. This is a component distinction. The IPC library is logically still part of the SCAL.

One of the supports provided by the System Call Adaptation Layer (SCAL) is the mapping of operations on UNIX® file descriptors to the corresponding Symbian OS resource objects. The section below discusses the file descriptors case.

Creating a new file descriptor

The porting of the 'C' POSIX fopen() function, below, is a good example of mapping POSIX handles to native Symbian OS resource objects. The mapping is done through a file descriptor table. As a reminder, every application/process has its own file descriptor table.

This example shows a call to the fopen() function:

//myapp.cpp
int foo()
{
   //open the test.tx , fd=7 in this example
   int fd = fopen("c:/test.txt", "r+");
   ...
   //writes to file referenced by the file descriptor  
   ret = write (fd, buf, size_t);

}

When myapp tries to open the file with fopen(), the application makes a call to the equivalent Symbian OS function, RFile::Open(), and returns the next free entry in the file descriptor table.

In each table, the values 0, 1 and 2 are reserved for stdin(), sdtout() and stderr(). The figure below shows an example file descriptor table.

According to the descriptor table the file descriptor equals 7, as this was the next free entry in the table, and the write function will be writing to the file referenced by 7.

Note: A POSIX descriptor is an index in the process open file table and represents, for example, an open file, socket or pipe. A Symbian descriptor represents data which can reside in any memory location, either in ROM or RAM. A descriptor object maintains pointer and length information to describe the data. All access to the data is made through the descriptor object.

Descriptors shared across multiple threads within the same process

Originally in Symbian OS, resources were thread specific and multi-tasking was achieved using servers and active objects. In other operating systems, such as Linux, resources are process-local and multi-tasking is achieved by multi-threading. The purpose of the POSIX server in the original STDLIB was to allow system-wide data, resources and descriptors to be shared across multiple threads. This means there was context switching between the calling thread and the server thread which added latency.

With the introduction of the EKA2 kernel, session handles can now be shared across multiple threads and processes.

P.I.P.S. takes advantage of EKA2 and re-factors the SCAL to allow descriptors to be shared across multiple threads within the same process, without the use of the POSIX server.