Porting the Unix rtl to a new target: what changed
Revision 0 to 1. Removed lines have a minus sign; added lines have a plus sign.
Title: Porting the Unix rtl to a new target
| Old | New | Line | |
|---|---|---|---|
| 1 | + | # Porting FPC | |
| 2 | + | ||
| 3 | + | Very global instructions to porting FPC to a *nix clone on a supported architecture: | |
| 4 | + | ||
| 5 | + | ## Setting up a new target in the compiler | |
| 6 | + | ||
| 7 | + | (typically only done when the RTL already works, and the first program runs, using a similar target) | |
| 8 | + | ||
| 9 | + | A few things must be done for a new target: (ARCH-OS combination, assuming ARCH is supported) | |
| 10 | + | ||
| 11 | + | - Define enumerations (tsystem) for this target in systems.pas. Only append, changing the order breaks compability. | |
| 12 | + | - A record with some parameters for the ARCH-OS combination must be defined in compiler/systems/i_*. If you only ported the OS to a new architecture, you can add it to the existing i_OS file. | |
| 13 | + | - An object that handles calling the linker must be registered. These objects reside in compiler/systems/t_*. Reuse an existing one, or create a new one. Registering must be done in \$ARCH/cputarg.pas file, by including the t_ unit. Also don't forget to review the initialisation code of the t_ unit if you adapt an existing one. | |
| 14 | + | - the startupcode of systems.pas must be adapted to select your target as default, under ifdef for the default OS-ARCH. | |
| 15 | + | ||
| 16 | + | If you get stuck on some linking problem, try to link a simple C program with some verbosity options turned on. (either static or linking to libc, depending on what you are trying). | |
| 17 | + | ||
| 18 | + | A more detailed list of needed changes inside the compiler can be found at [[Porting Free Pascal]]. | |
| 19 | + | ||
| 20 | + | ## Porting the RTL | |
| 21 | + | ||
| 22 | + | Porting the Unix rtl is typically more work then the stuff above. | |
| 23 | + | ||
| 24 | + | Typically it boils down to take the closest relative (rtl/freebsd/, and start checking and converting) | |
| 25 | + | ||
| 26 | + | There are a few typical problem points: | |
| 27 | + | ||
| 28 | + | - ftruncate, lseek, mmap and other calls that have 64-bits arguments and returnvalues. The exact handling and calling conventions of these changes per unix flavour and even per architecture. | |
| 29 | + | - The startup code must be adapted. Twice. One for linking without libc (prt0), one for with libc (cprt0). Others (like gprt0) are only for profiling and basically a slightly modded cprt0 | |
| 30 | + | - signal to runtime error procedure must be reviewed. The way to get access to the registerstate is highly arch + OS dependant. The texception* tests in the testsuite are good tests for this. | |
| 31 | + | ||
| 32 | + | ### startup code | |
| 33 | + | ||
| 34 | + | The startup code mods are typically done by compiling the crt0 sources with -S to generate assembler AND compare with a objdumped small static binary. (the latter will reveal stuff like ELF identifiers), and checking with a comparable FPC existing startup code. | |
| 35 | + | ||
| 36 | + | Typical modifications both prt0 and cprt0.as: | |
| 37 | + | ||
| 38 | + | - reserve room for a few variables (FPC_*, operatingsystem*) | |
| 39 | + | - fixup copro status word (x86) | |
| 40 | + | - move argc,argv,envp to FPC namespace. | |
| 41 | + | - Empty framepointer before calling main (xorl %ebp,%ebp) | |
| 42 | + | - beware of ELF identifiers. | |
| 43 | + | ||
| 44 | + | prt0 can strip the whole libc init/finalisation, cprt0 must preserve it. | |
| 45 | + | ||
| 46 | + | --- | |
| 47 | + | *From the Free Pascal wiki, page "Porting the Unix rtl to a new target", as it stood on 2014-04-23 after a change by BigChimp, out of the wiki's dump of 2024-05-26. Copyright stays with the author who wrote it, according to the old wiki's [[Licensing]] page. If you have concerns about this material, [message the admin](/wiki-contact).* | |
| 48 | + | Category: RTL | |
| 49 | + | Category: Unix |