Syscall implementieren

[MitjaStachowiak]

Hallo,
weiß jemand, wie ich z.B. den sched_setaffinity-Syscall in Lazarus verwende? Ich habe dankenswerter Weise hier im Forum von MSE mal den Code für den shm-Open-Call bekommen:

Code: Alles auswählen

  const {$ifdef linux}shmlib = 'rt';{$else}shmlib = clib;{$endif}
  function shm_open(name: pchar; oflag: longint; mode: Cardinal): longint; cdecl; external shmlib name 'shm_open';
 

Entsprechend hierzu die man-Page: http://man7.org/linux/man-pages/man3/shm_open.3.html
Dort steht "link with lrt" - daher das shmlib = 'rt'.

Bei sched_setaffinity steht kein solcher Kommentar: http://man7.org/linux/man-pages/man2/sc ... ity.2.html
Die Deklaration sollte wie folgt aussehen:

Code: Alles auswählen

  function sched_setaffinity(pid: Cardinal; cpusetsize: Cardinal; const mask: PByte): longint; cdecl; external '???' name 'sched_setaffinity';

Aber was muss ich für die ??? einsetzen?

[mse]

Aber was muss ich für die ??? einsetzen?

Code: Alles auswählen

c

Die wrapper sind in der glibc.

[MitjaStachowiak]

Toll, scheint zu gehen, besten Dank

Verrätst du mir noch, woher man das jetzt wissen konnte? Sind alle Syscalls, bei denen keine extra library angegeben sind 'c' oder wie muss man sich das vorstellen?

[mse]

http://man7.org/linux/man-pages/man3/shm_open.3.html
ist ein "man3" Eintrag, das heisst er bezieht sich auf libc, wenn nichts anderes steht, wird mit -lc gelinkt.
http://man7.org/linux/man-pages/man2/sc ... ity.2.html
ist ein "man2" Eintrag, das heisst es geht um einen SYSCALL. Es werden die glibc Wrapper-Funktionen erwähnt:

VERSIONS
The CPU affinity system calls were introduced in Linux kernel 2.5.8.
The system call wrappers were introduced in glibc 2.3. Initially,
the glibc interfaces included a cpusetsize argument, typed as
unsigned int. In glibc 2.3.3, the cpusetsize argument was removed,
but was then restored in glibc 2.3.4, with type size_t.

Darum habe ich mit MSEide in den Header-Dateien nach "sched_setaffinity" gesucht und in /usr/include/sched.h einen entsprechenden Eintrag gefunden, vermutet dass die Funktion in libc.so.6 gelinkt ist und daher mit 'c' probiert.

Zur Kontrolle, nm listet den Eintrag:

Code: Alles auswählen

 
nm /lib/libc.so.6 | grep sched_setaffinity
0012b370 T sched_setaffinity@GLIBC_2.3.3
000d2b80 T sched_setaffinity@@GLIBC_2.3.4
000d2b80 t __sched_setaffinity_new
0012b370 t __sched_setaffinity_old
 

[MitjaStachowiak]

Da dann wolln wa mal sehen, ob ich das nächstes mal alleine schaffe
Noch folgendes Problem: Aktuell sieht das bei mir so aus:

Code: Alles auswählen

type
  size_t = Integer;
  ssize_t = Cardinal;
  pid_t = Cardinal;
 
function sched_setaffinity(pid: pid_t; cpusetsize: size_t; const mask: PByte): Integer; cdecl; external 'c' name 'sched_setaffinity';
function readlink(const pathname: PChar; var buf; bufsize: size_t) : ssize_t; cdecl; external 'c' name 'readlink';
 

Ich hoffe, dass die Typen für size_t so stimmen. Das readlink geht auf meinem x86 auf jeden Fall. Das ganze soll dann später auf einem ARM-Soc laufen.

Aktuell hänge ich daran, das mit dem Crosscompiler zu linken. Habe FPC als Crosscompiler Linux i386 -> Linux arm eingerichtet. Kann das Programm ohne die Syscalls auch für ARM kompilieren. Mit kommt wieder ein Linker Error. Heißt dass ich muss eine "cross-glibc" für ARM nachinstallieren, damit der Linker das findet?

Oder gibt es die Möglichkeit, das dynamisch zu machen? Auf Windows muss eine verwendete DLL ja auch nicht installiert sein, damit man es zumindest kompilieren kann.

[mse]

Ich hoffe, dass die Typen für size_t so stimmen. Das readlink geht auf meinem x86 auf jeden Fall. Das ganze soll dann später auf einem ARM-Soc laufen.

MSEgui hat die Units msectypes und mselibc worin diese Typen für die Linux und FreeBSD Versionen definiert sind.
https://gitlab.com/mseide-msegui/mseide ... ctypes.pas
https://gitlab.com/mseide-msegui/mseide ... selibc.pas
Auch Free Pascal hat eine ctypes-Unit.

Aktuell hänge ich daran, das mit dem Crosscompiler zu linken. Habe FPC als Crosscompiler Linux i386 -> Linux arm eingerichtet. Kann das Programm ohne die Syscalls auch für ARM kompilieren. Mit kommt wieder ein Linker Error. Heißt dass ich muss eine "cross-glibc" für ARM nachinstallieren, damit der Linker das findet?

Ja. Es müssen auch Links lib*.so -> lib*.so.n vorhanden sein, siehe den ewigen Bugreport https://bugs.freepascal.org/view.php?id=32367
erste Diskussionen über das Thema liegen 10 Jahre zurück.
Vollständige Cross-Compiling-Debugging Umgebungen Linux -> ARM (Raspberry Pi) sind hier:
https://sourceforge.net/projects/mseide ... pcrossarm/
Für MSEide gibt es auch ein entsprechendes Projekttemplate, siehe MSEide+MSEgui README.TXT.
Du könntest zuerst mit RPi üben und dich mit dem SOC herumschlagen, sobald es auf dem RPi grundsätzlich funktioniert.
Für Embedded gibt es auch eine entsprechende Version:
https://sourceforge.net/projects/mseide ... membedded/
Siehe auch
http://www.lazarusforum.de/viewtopic.ph ... 17#p102817

Oder gibt es die Möglichkeit, das dynamisch zu machen? Auf Windows muss eine verwendete DLL ja auch nicht installiert sein, damit man es zumindest kompilieren kann.

Man könnte GetProcAddress() verwenden statt "statically shared" zu linken. Entsprechende Routinen sind hier:
https://gitlab.com/mseide-msegui/mseide ... ynload.pas
AFAIK braucht der Linux Linker für "statically shared" Zugriff auf die Bibliothek zur Kompilierzeit unter anderem um den SONAME zu bestimmen.

[MitjaStachowiak]

Dynamisch linken geht leider nicht, weil dynlibs selbst wieder eine statische Verlinkung braucht, die nicht im cross-compile geht.

Sehe ich das richtig, dass FPC seit Version 2.irgendwas seinen eigenen Linker mitbringt?

Ich bekomme die Warnungen crtbegin.o und crtend.o not found. Diese Dateien habe ich in deinem Projekt gefunden. Mein ARM-FPC ist in /usr/lib/fpc/3.0.4 installiert. Jedenfalls habe ich mal die .o-Files aus deinem eabi zu meinem aktiven ppcrossarm in /usr/lib/fpc/3.0.4 kopiert. Dann Bekomme ich die Meldung

Code: Alles auswählen

/usr/lib/x86_64-linux-gnu/crti.o: file not recognized: File format not recognized

Komisch - wieso nimmt er hier nicht die crti.o, die ich in das ppcrossarm-Verzeichnis kopiert habe?

Also die Einstellungen in der /etc/fpc.cfg zu -Fu verweisen auf das units-Verzeichnis im fpc/3.0.4-Ordner. Es ändert aber nichts, wenn ich hier etwas anderes einstelle. Vielleicht werden diese units im aktuellen Projekt nicht benötigt... Aber wo ist der Unterschied zu den .o-Files in units und denen, die ich aus eabi kopiert habe?

[mse]

Dynamisch linken geht leider nicht, weil dynlibs selbst wieder eine statische Verlinkung braucht, die nicht im cross-compile geht.

Das sollte man schon hinkriegen, sonst ist Hopfen und Malz verloren.

Sehe ich das richtig, dass FPC seit Version 2.irgendwas seinen eigenen Linker mitbringt?

AFAIK nur für Windows.

Ich bekomme die Warnungen crtbegin.o und crtend.o not found.

Ich kann dir nur empfehlen, als ersten Versuch die unveränderten Umgebungen in
https://sourceforge.net/projects/mseide ... z/download
für 64 Bit Linux Host
https://sourceforge.net/projects/mseide ... z/download
für 32 Bit Linux Host
mit einem RPi und dem MSEide crossarm* Projekttemplate auszuprobieren. Bei mir und weiteren Usern funktioniert das.
Aus README.TXT:

Code: Alles auswählen

 
Crosscompiling and remote debugging i386/x84_64-linux -> arm-linux
***********************************************************
For Raspberry Pi:
- Establish a ssh login without password (public key authentication).
 
- On the i386/x84_64-linux host install the scp program
- download and extract 
  https://sourceforge.net/projects/mseide-msegui/files/fpcrossarm/crossfpc-i386_linux_eabihf_3_0_5.tar.gz
  (or crossfpc-x86_64_linux_eabihf_3_0_5.tar.gz)
  to <your crossfpc directory>.
 
- Start MSEide, in 'Settings'-'Configure MSEide'-'Global Macros' add:
 
Name            Value
 
CROSSMSEDIR     <MSEide+MSEgui directory>
CROSSFPCDIR     <your crossfpc directory>
CROSSFPCVERSION 3.0.5
HOSTIP          <the IP address of the host>
REMOTEIP        <the IP address of the remote target>
REMOTEPORT      <the remote port, ex: 2345>
REMOTEUSER      pi
 
- 'Project'-'New'-'From Template', select "crossarmdefault.prj" or
  "crossarmconsole.prj".
- Create the new project.
- 'Project'-'Options'-'Macros', set the TARGETPROJECTDIR value to the project
  path in remote target, ex: "/home/pi/proj/testcase".
- Check the TARGETENV macro.
- If your application needs additional libraries copy them from Raspberry Pi
  /lib/arm-linux-gnueabihf or /usr/lib/arm-linux-gnueabihf to
  <your crossfpc directory>/eabihf/lib
 
Press F9 and hope the best. ;-)
If there is a debugger timeout at startup enlarge the 
'Project'-'Options'-'Target'-'Wait before connect' value.
 

Sobald es funktioniert kannst du anhand des Musters deine eigene Entwicklungsumgebung auf Vordermann bringen.
Ich werde noch MSEide RPi Demoprojekte machen.
Edit:
Ich nehme an, dass auf deinem SoC Linux läuft. Korrekt?

[mse]

Ich werde noch MSEide RPi Demoprojekte machen.

Hier:
https://gitlab.com/mseide-msegui/mseuni ... aspberrypi

[MitjaStachowiak]

Danke, mit den Zusatzinfos habe ich es geschafft: Man muss das Verzeichnis mit den .so-Files in der fpc.cfg über die -Fl hinzufügen, nicht wie im Wiki beschrieben mit -Xr. Dort stehen zwei Zeilen mit -Xr, das ist doch bestimmt ein Fehler, oder?

Naja, jetzt linkt es. Leider bekomme ich auf dem Zielsystem einen Segmentation Fault (mit und ohne die syscalls). Das soll auf einem Xilinx ZedBoard laufen (ARM Cortex™-A9, Linux-4.9.0-mathworks). Werde es nachher erst mal auf meinem PI starten, um zu sehen, ob es daran liegt.

[marcov]

AFAIK nur für Windows.

(Etwas später (2.4?) auch fuer Dos/go32v2, und in trunk fuer 16-bit Dos)

[MitjaStachowiak]

Auf dem PI bekomme ich auch einen Speicherzugriffsfehler. Irgendwas ist noch falsch...

[mse]

Auf dem PI bekomme ich auch einen Speicherzugriffsfehler. Irgendwas ist noch falsch...

Nochmals der Hinweis auf die Demoprojekte:
Konsole
https://gitlab.com/mseide-msegui/mseuni ... helloworld
Graphisch
https://gitlab.com/mseide-msegui/mseuni ... pi/minimal