Difference between revisions of "System unit structure"

From Lazarus wiki
Jump to navigationJump to search
m (put Template:stub at bottom; xref System unit)
(Added part explaining used files and their location)
Line 6: Line 6:
  
 
All listed routines are mandatory (at least as stub) unless specifically mentioned otherwise. If name of the usual source file containing implemenation of the particular routine is not mentioned, it's supposed to be system.pas for platform specific parts and system.inc for the shared routines.
 
All listed routines are mandatory (at least as stub) unless specifically mentioned otherwise. If name of the usual source file containing implemenation of the particular routine is not mentioned, it's supposed to be system.pas for platform specific parts and system.inc for the shared routines.
 +
 +
== Source file structure ==
 +
 +
Similarly to other parts of FPC RTL (and also units included in packages), the general pattern is that units requiring at least some platform / target specific parts have the main source file (system.pas in case of unit System) in the specific subdirectory specific for the particular target, but this file refers an include file containing the common interface (systemh.inc) and another include file containing implementation of platform independent stuff (system.inc) - obviously, we try to share as much as possible rather than duplicating the same code on several places. The parts shared for all targets (like the two include files mentioned above) are stored in /rtl/inc.
 +
 +
In the particular case of unit System (and partly also some other more complex units), there are quite a few more include files involved, though. In addition to parts which are shared among all targets, there are also parts which may be shared for all targets on a particular CPU / platform stored in a subdirectory named after the CPU / platform (e.g. in /rtl/i386/, /rtl/x86_64/, /rtl/aarch64/, /rtl/jvm/, etc.). Moreover, there may be parts which are shared by several targets having certain similar aspects - e.g. various BSD based targets have shared parts in /rtl/bsd/, all *NIX targets have shared parts in /rtl/unix/ and various MS Windows targets may use shared parts in /rtl/win/.
 +
 +
Finally, the complexity of the System unit led to the situation that the common implementation part expects certain parts of the target-specific implementation in specifically named include files which need to be made available in the subdirectory for the particular target, or possibly in a subdirectory shared among several targets as mentioned above. As an example, target specific implementation of file handling needs to be provided in file sysfile.inc.
 +
 +
You might wonder how the compiler knows where to find the different include files - this is handled in the Makefile (generated from Makefile.fpc rules using our fpcmake tool - see /utils/fpcm/).
 +
  
 
== Types ==
 
== Types ==
Line 130: Line 141:
 
<TODO>
 
<TODO>
  
 
==== InitSystemThreads ====
 
 
<TODO>
 
  
 
== General tasks ==
 
== General tasks ==

Revision as of 14:38, 21 March 2021

English (en) español (es) français (fr)

(work in progress - incomplete!)

This page is supposed to document functions and procedures serving as "interfaces" between common and platform specific parts of unit System as well as commonly used subroutines for particular tasks performed during unit System initialization and specify their behaviour. This should then serve as specification for maintainers of existing and new platforms to ensure fully compatible behaviour (as far as possible considering limitations of the individual platforms).

All listed routines are mandatory (at least as stub) unless specifically mentioned otherwise. If name of the usual source file containing implemenation of the particular routine is not mentioned, it's supposed to be system.pas for platform specific parts and system.inc for the shared routines.

Source file structure

Similarly to other parts of FPC RTL (and also units included in packages), the general pattern is that units requiring at least some platform / target specific parts have the main source file (system.pas in case of unit System) in the specific subdirectory specific for the particular target, but this file refers an include file containing the common interface (systemh.inc) and another include file containing implementation of platform independent stuff (system.inc) - obviously, we try to share as much as possible rather than duplicating the same code on several places. The parts shared for all targets (like the two include files mentioned above) are stored in /rtl/inc.

In the particular case of unit System (and partly also some other more complex units), there are quite a few more include files involved, though. In addition to parts which are shared among all targets, there are also parts which may be shared for all targets on a particular CPU / platform stored in a subdirectory named after the CPU / platform (e.g. in /rtl/i386/, /rtl/x86_64/, /rtl/aarch64/, /rtl/jvm/, etc.). Moreover, there may be parts which are shared by several targets having certain similar aspects - e.g. various BSD based targets have shared parts in /rtl/bsd/, all *NIX targets have shared parts in /rtl/unix/ and various MS Windows targets may use shared parts in /rtl/win/.

Finally, the complexity of the System unit led to the situation that the common implementation part expects certain parts of the target-specific implementation in specifically named include files which need to be made available in the subdirectory for the particular target, or possibly in a subdirectory shared among several targets as mentioned above. As an example, target specific implementation of file handling needs to be provided in file sysfile.inc.

You might wonder how the compiler knows where to find the different include files - this is handled in the Makefile (generated from Makefile.fpc rules using our fpcmake tool - see /utils/fpcm/).


Types

The following types are assumed to be defined in platform specific part of System unit interface.

  • THandle
  • TThreadID
  • TRTLCriticalSection
  • PRTLCriticalSection

Constants and variables

The following list includes mandatory constants and variables that have to be declared (and usually initialized to reasonable values for the particular platform) for all platforms:

  • LineEnding
  • DirectorySeparator
  • DriveSeparator
  • PathSeparator
  • MaxExitCode
  • MaxPathLen
  • UnusedHandle
  • StdInputHandle
  • StdOutputHandle
  • StdErrorHandle
  • LFNSupport
  • FileNameCaseSensitive
  • CtrlZMarksEof
  • sLineBreak
  • DefaultTextLineBreakStyle
  • ArgC
  • ArgV
  • EnvC
  • EnvP


<TODO>

Initialization

Shared

InitHeap

Implemented in heap.inc.

Initialization of internal structures used by the default heap memory manager. No heap may be used before calling InitHeap.

SysInitExceptions

Initialization of internal structures used by the exception support.

<TODO>

OpenStdIO

Common part of initialization for standard file variables. It's similar to Assign and Reset/Rewrite calls for normal text files, but the files are associated with empty file names and no attempt is made to open the files (they're assumed to be already open).

<TODO>

InitSystemThreads

<TODO>

SetThreadManager

<TODO>

InitHeapMutexes

<TODO>

InitVariantManager

<TODO>

InitWideStringManager

<TODO>

Sysinit unit and indirect entry information

(note: This is currently at very initial stage and applies only to i386-win32 target)

Supporting runtime packages requires possibility to link the system unit and the main program into different executable modules. Therefore, global information generated by compiler, such as unit initialization table, cannot be directly referenced from the system unit. Instead, it is referenced from a separate small unit ('sysinit') and passed to routines in system unit via function arguments. The module entry point is placed in sysinit unit, too. A copy of sysinit unit is statically linked into every executable module, so every module ends up containing the initialization table only for the units it actually contains.

This global information is not limited to unit initialization table, see TEntryInformation record for complete list.

A target may have more than one sysinit unit, each solving specific initialization tasks. A particular unit to use is determined by compiler, see InitSysInitUnitName method in descendants of TLinker class. For example, while normally using sysinitpas.pp, complier will use sysinitcyg.pp instead if it detects linking with cygwin libraries.

Platform specific

unit initialization

The following tasks are performed:

  • IsLibrary variable initialization (true if running in a shared library, false otherwise)
  • ProcessID and ThreadID variables initialization
  • IsConsole variable initialization (true if running in a text console, false if running in windowed GUI application)
  • ExitProc variable initialization <TODO>
  • Heap initialization (calling shared InitHeap)
  • Initialization of potential procedural variables and/or parameters needed to support System unit routines requiring different implementation depending on detected version of operating system (possibly including dynamic loading of procedures or functions from shared libraries where appropriate) - see OS aware RTL
  • InOutRes variable initialization (set to 0)
  • Environment variables initialization (EnvC and EnvP), usually by calling InitEnvironment - only needed for platforms not providing access to these variables natively
  • Internal thread manager is initialized by calling InitSystemThreads
  • Internal variant manager is initialized by calling InitVariantManager
  • Internal widestring manager is initialized by calling InitWideStringManager

InitEnvironment

Only needed for platforms not providing access to EnvC and EnvP variables natively.

Procedure checks amount of environment variables and stores it in EnvC. Then memory for EnvP^ is allocated from heap (array of EnvC + 1 items of type PChar - the list pointer will point to nil). Finally the individual items in the array are initialized with PChars pointing to null terminated strings containing the environment variable name, equal sign and the environment variable value. Memory for the individual null terminated strings may be allocated from heap for these strings and they may be copied there if needed (i.e. if the particular platform doesn't provide pointer to a fixed location for these strings in required format).

InitArguments

Only needed for platforms not providing access to ArgC, ArgV and/or CmdLine variables natively.

<TODO>

SysInitStdIO

Initialization of standard file variables (Input, Output, ErrOutput, StdOut and StdErr).

<TODO>


General tasks

Platform specific

File handling

Usually implemented in file sysfile.inc.

Do_Close
Do_Erase
Do_Rename
Do_Read
Do_Write
Do_FilePos
Do_Seek
Do_SeekEnd
Do_FileSize
Do_Truncate
Do_Open
Do_IsDevice

Heap management

SysOSAlloc
SysOSFree

Threading Support

SysInitThreadVar
SysRelocateThreadVar

Other

System_Exit

Public routines

The following routines are part of System unit interface and are supposed to be implemented fully in platform specific way. Their specification is available in FPC documentation, so they're listed here mostly for completeness sake to provide complete list for porting purposes.

Directory handling

Usually implemented in sysdir.inc.

  • MkDir
  • RmDir
  • ChDir
  • GetDir

Other

  • Randomize
  • ParamCount, ParamStr (possibly to be moved to common - <TODO>)


Finalization

Shared

InternalExit

<TODO>

FinalizeHeap

<TODO>

Platform specific

FinalDeallocation

<TODO>

An editor has declared this article to be a stub, meaning that it needs more information. Can you help out and add some? If you have some useful information, you can help the Free Pascal Wiki by clicking on the edit box on the left and expanding this page.