Assembler Module mit CMake

So wie es in Star Trek heißt

Space, the final frontier.

so heißt es dann auch gerne in der Software-Entwicklung:

Assembler, the final frontier.

Bleibt nur die Frage offen, wie man diese letzte Grenze dann auch in CMake überwindet.

Das GATE Projekt soll eigentlich frei von Hardware-Spezialitäten sein, lediglich die “notwendigen” OS APIs der wichtigsten Hersteller sollen gesammelt und abstrahiert werden.
Assembler Codes haben da keinen Platz und sind auch in anderen Libs wie OpenSSL / libreSSL usw. bewusst abgeschaltet.

Eine kleine Ausnahme gibt es, wenn es um die CPU-ID geht, die man mit Inline-Assembler auslesen kann … aber schon da gibt es das typische MSVC X64 Problem, dass dort nämlich kein Inline-Assembler unterstützt wird.

Mit der EFI Plattform gibt es nun aber einen Sonderfall, wo es um den Nachbau von C-APIs geht, namentlich setjmp() und longjmp().

Diese Funktionen lassen sich nicht mit reinem C nachbauen. Doch diese sind in der gnuefi Bibliothek als .s Assembler Dateien beigelegt.

Blöd ist nur, dass ich primär unter Windows mit dem MSVC arbeite, wo mir erstens die .s Dateien nichts bringen und zweitens CMake diese Dateien nicht automatisch mitbaut.

GNU Assembler Support für CMake

Im Netz findet man schnell die Info, dass man ASM als Sprache im CMake Projekt angeben soll, also z.B.
project(my_project C ASM)

Dann werden noch *.s Dateien hinzugefügt und man erhält:

  project(my_project C ASM)
 
  file(GLOB MY_ASM_SOURCES
    "path/to/*.s"
  )
  file(GLOB MY_C_SOURCES
    "path/to/*.c"
  )
  
 add_library(my_project
   ${MY_ASM_SOURCES}
   ${MY_C_SOURCES}
 )

CMake generiert dann Make-Files, die die .s Assembler Dateien kompilieren und zur Zielbibliothek (oder Executable) hinzufügen.

MSVC Assembler Support für CMake

In Visual Studio kann man manuell den MASM Support aktivieren, in dem man das Projekt auswählt, und dann unter Project - Build Customizations klickt und dort die masm Zeile anhakt. Ab dann werden alle .asm Dateien an den Assembler Compiler weitergereicht.

Für CMake gibt es beim MSVC einen eigenen MASM Token, der da lautet:
ASM_MASM.

Somit muss man nur noch die unter DOS und Windows üblichen .asm Dateien in CMakeLists.txt aufnehmen:

  project(my_project C ASM_MASM)
 
  file(GLOB MY_ASM_SOURCES
    "path/to/*.asm"
  )
  file(GLOB MY_C_SOURCES
    "path/to/*.c"
  )
  
 add_library(my_project
   ${MY_ASM_SOURCES}
   ${MY_C_SOURCES}
 )

MASM Funktionen für C schreiben

Nun beginnt für mich der harte Kampf die AT&T Assemblercodes nach MASM zu portieren. Denn da der AT&T Syntax bei GNU und GCC vorherrscht und auch die setjmp() und longjmp() Codes der gnu-efi Bibliothek so geschrieben sind, müssen fast alle Codezeilen “umgedreht” werden, damit sie MASM-tauglich werden.

Warum MASM ein Operator Ziel, Quell Schema verfolgt und AT&T umgekehrt Operator Quelle, Ziel nutzt und es da keinen Standard gibt, stört mich damals wie heute.

So sehen jedenfalls meine vorläufigen Bemühungen aus:

 .CODE
 
 PUBLIC _setjmp
 
 _setjmp PROC
   ; RCX hold pointer to jmp_buf 
   pop rdx   ; RET address
   push rdx
   mov rax, 0
  mov [rcx + 00h], rsp  ; Frame
  mov [rcx + 08h], rbx                
  mov [rcx + 10h], rsp
  mov [rcx + 18h], rbp
  mov [rcx + 20h], rsi
  mov [rcx + 28h], rdi
  mov [rcx + 30h], r12
  mov [rcx + 38h], r13
  mov [rcx + 40h], r14
  mov [rcx + 48h], r15
  mov [rcx + 50h], rdx ; RIP
  ; currently, skip following fields in jmp_buf
  ret
_setjmp ENDP

PUBLIC longjmp

longjmp PROC
  mov rbx, [rcx + 08h]
  mov rsp, [rcx + 10h]
  mov rbp, [rcx + 18h]
  mov rsi, [rcx + 20h]
  mov rdi, [rcx + 28h]
  mov r12, [rcx + 30h]
  mov r13, [rcx + 38h]
  mov r14, [rcx + 40h]
  mov r15, [rcx + 48h]

  mov r8, [rcx + 50h] ; RIP

  mov eax, edx
  and rax, 0ffffffffh
  cmp eax, 0
  jne longjmp_exit
  mov eax, 1
longjmp_exit:
  jmp r8
longjmp ENDP

Fazit

Der erste Schritt ist also getan. Die in Assembler implementierten setjmp() und longjmp() Symbole erlauben mir nun weitere Bibliotheken wie LUA oder libjpeg auch für native EFI-Apps zu nutzen.

Das Potential ist aber weit größer.
Denn mit Assembler-Fragmenten kann ich nun auch zu anderen Stacks springen und z.B. Koroutinen ohne OS-Support implementieren.

Aber … bis das lauffähig sein wird, vergeht vermutlich noch einige Zeit.