Communication between these cores is essential, but there is no single standard to achieve this. OpenAMP, with its RPMsg and RemoteProc components, provides a flexible and widely adopted solution for intercommunication between Linux and RTOS or bare-metal systems.

What will and will not be covered​

This article focuses on the principles of inter-processor communication between heterogeneous processors (Linux and RTOS) in embedded systems, using OpenAMP and its components. We will explain how the key mechanisms work (RPMsg, RemoteProc, IPCC, VirtIO). We will not dive into implementation details (assembly code, hardware registers).

Prerequisite​

• ARM Programming (STM32): basic knowledge of the ARM architecture.
• C language: used for embedded development.
• Understanding of an RTOS or Linux: basic concepts of real-time operating systems (RTOS) and/or Linux.

Targeted audience​

• Engineering students interested in exploring multi-core embedded systems.
• Beginner engineers in the field of embedded software.

Global Overview​

To better understand the architecture, here’s a diagram that illustrates the separation between the Linux and RTOS environments, and the communication mechanisms between them:

Figure 1: OpenAMP architecture overview between Linux and RTOS

Booting and managing the remote core​

How does IPCC work?​

IPCC (Inter Processor Communication Channel) is a hardware peripheral found on some STM32 microcontrollers, such as the STM32MP1 family. It allows interrupts to be triggered between microcontrollers.

This component consists of several channels. For example, the STM32MP257F has 16 channels on IPCC1 ^MP257F Lines.

Figure 2: How the IPCC hardware component is working for 6 channel (STM32MP157F)

A board may include multiple IPCC peripherals. They enable communication between two or more processors. The IPCC2 peripheral allows communication between all Cortex cores on the board.

Figure 3: Extract from the documentation of the STM32MP257F

Each channel has a specific function. For example, channel 3 ^MP257F Lines is used by the RemoteProc framework to shut down the Cortex-M33.

Life Cycle Management​

RemoteProc ¹ is a framework used to manage the lifecycle (boot, shutdown, supervision) of a remote processor. On Linux, RemoteProc can be used to load a firmware image onto a Cortex-M core (running an RTOS or bare-metal), monitor its state, or shut it down.

int remoteproc_start(struct remoteproc *rproc); 

int remoteproc_stop(struct remoteproc *rproc); 

int remoteproc_shutdown(struct remoteproc *rproc);

RemoteProc relies on specific drivers and on the firmware’s resource table to allocate shared memory and required peripherals.

Role of IPCC in triggering remote boot​

IPCC plays a key role in booting the remote core. When Linux wants to start a firmware on an RTOS core, it uses IPCC to send an initialization signal. This signal triggers the remote core boot process, allowing it to initialize its own environment. IPCC can also be used to synchronize other actions, such as data exchange or critical event notification.

Inter-Processor Data Exchange​

VirtIO​

Communication between cores primarily takes place through shared memory (SRAM).

VirtIO is a standard that defines a protocol for communication between drivers and devices of different types.

Ring Buffer​

The framework uses ring buffers, which can be seen as channels with their own queues.

VirtIO relies on a shared-memory ring buffer mechanism called VRing. Each VRing is made of two parts:

• AVAIL: A ring where the sender posts available buffers.
• USED: A ring where the receiver posts completed buffers.

Each side writes only to its own ring (sender to AVAIL, receiver to USED), preventing race conditions. VirtIO supports multiple VRings, allowing concurrent communication channels (e.g., one for commands, one for data, one for control messages).

Figure 4: Resource assignement example for IPC

RPMsg abstraction​

RPMsg is a VirtIO-based messaging bus that allows kernel drivers to communicate with remote processors present in the system. It provides the infrastructure to exchange wire-protocol messages between client drivers. These drivers can then expose appropriate user space interfaces if needed.

The RPMsg client driver implements a service associated with the remote processor. This driver is probed by the RPMsg framework when a corresponding service is announced by the remote processor via a “new service announcement” RPMsg message.

RPMsg Client Driver​

The RPMsg client driver serves to handle a specific communication service between cores. For example, if the remote core exposes a logging or file-access service, an RPMsg client driver on Linux receives the message and routes it to the appropriate Linux subsystem.

It abstracts the low-level messaging details, allowing developers to implement high-level inter-core services (e.g., sensor acquisition, control, logging, RPC).

Why recode this driver?​

You may want to re-implement or customize an RPMsg client driver in these situations:

• You are designing a custom protocol or service not covered by existing drivers.
• You need to support a proprietary message format or payload.
• You want to expose RPMsg messages to user space differently (e.g., via character device, netlink, or custom interface).
• You need to implement secure or encrypted communication on top of RPMsg.

By customizing the RPMsg client driver, developers can fully adapt the communication stack to their application's needs.

OpenAMP high-level interface​

OpenAMP’s high-level interface integrates and abstracts the complexities of managing remote cores and orchestrating inter-processor communication (IPC) in heterogeneous multicore environments. By leveraging RemoteProc for lifecycle management, RPMsg for robust messaging, and VirtIO for virtual device abstraction.

OpenAMP enables seamless control and data exchange between master and remote processors—regardless of whether they run Linux, RTOS, or bare-metal firmware.

The framework’s support for various topologies (star, chain, or combined) and its compatibility with industry-standard IPC mechanisms (such as IPCC, Mailbox, and RPMsg) further enhance its flexibility and reliability in real-world deployments.

OpenAMP Proxy​

The framework’s proxy mechanism extends this interoperability, allowing system calls such as open, read, and write to be transparently forwarded from an RTOS or bare-metal context to Linux, effectively giving remote cores access to host filesystem resources without requiring a full OS stack.

This is really valuable in scenarios where resource-constrained remote cores need to offload I/O operations to a more capable master processor.

What's the difference between Linux and FreeRTOS on IPC?​

The main difference between Linux and FreeRTOS regarding Inter-Processor Communication (IPC) lies in the abstraction layers and available mechanisms:

Linux: Drivers and frameworks (RemoteProc, RPMsg, VirtIO) are tightly integrated into the kernel. This integration provides fine-grained control over resources and peripherals, enabling robust and scalable IPC solutions. For instance, on STM32MP1xx, Linux can communicate with the Cortex-M4 core using OpenAMP-based virtual UART devices, which appear as TTY devices in the Linux filesystem and allow for message passing and synchronization via shared memory and IPCC peripherals.

FreeRTOS (or RTOS in general): OpenAMP provides a lightweight library implementing similar concepts as Linux, but with an interface simplified for real-time constraints. Each vendor porting OpenAMP provides an implementation of libmetal for their system. For example, STM32MP1xx has strong support for OpenAMP, with documentation and examples dedicated to testing the library on these devices.

LibMetal​

LibMetal is the abstraction layer used by OpenAMP to manage hardware resources and portability. On FreeRTOS, libmetal is typically provided by the vendor and adapted to the specific hardware and RTOS environment, enabling OpenAMP to function across different platforms and RTOSes.

For instance, on STM32MP1xx, the OpenAMP middleware initializes and configures the IPCC peripheral through HAL, sets up the OpenAMP/RPMsg framework, and creates virtual UART instances for IPC. The Cortex-M4 firmware (running FreeRTOS or bare metal) communicates with Linux on the Cortex-A7, using shared memory and IPCC for synchronization.

Closing remarks​

OpenAMP is a powerful framework for intercommunication between Linux and RTOS or bare-metal cores in multi-core embedded systems. It relies on open standards (RPMsg, VirtIO, RemoteProc) and uses hardware peripherals such as IPCC for synchronization. Understanding these mechanisms is essential to designing modern, flexible, and high-performance embedded systems.

However, it’s important to remember that, like in any field (and especially in IT) this technology is just one among many. If this topic has piqued your interest, I encourage you to learn more about Symmetric Multi-Processing ² (SMP).

Glossary​

• LCM – Life Cycle Management of remote processor: managing the remote processor's lifecycle (boot, stop, supervision).
• RPMsg – Lightweight messaging protocol used over shared memory.
• RemoteProc – Framework for booting and managing remote cores.
• IPCC – Hardware peripheral for signaling between processors.
• AMP – Asymmetric Multi-Processing: architecture where multiple processors run different operating systems.
• OpenAMP – Middleware for AMP communication (based on RPMsg + RemoteProc).
• VirtIO - Standard that allows virtual machines to efficiently access simplified virtual devices, such as network and storage.
• VRing – A data structure (ring buffer) defined by the VirtIO specification, used to organize and exchange buffers.

References and Further Reading​

Virtio Mechanisms​

• Linux Virtio
• Virtio Specification v1.2

IPCC Mechanisms​

• STM32 IPCC
• Zephyr IPC Service
• AN5617: IPCC Application Note

OpenAMP Library​

• Introduction to OpenAMP Library (Whitepaper)
• Coprocessor Management Overview on STM32MPx
• STM32 Dual Core - Inter-core communication using HSEM (YouTube)

RPMsg​

• Linux RPMsg on OpenStLinux
• Develop on Arm (STM32MP157x-EV1)
• Linux RPMsg driver source
• Exchanging buffers with RPMsg

Additional resources​

• Yocto meta-ipc layer

Pinsyscalls ?​

Avant de voir comment désactiver un pinsyscalls, cela peut être intéressant de voir ce que cela signifie. Le kernel OpenBSD a mise en place une sécurité particulière sur ces syscalls. Cela a pour but de faire en sorte qu'un syscall ne puisse être call que dans une certaine plage d'addresse dans un binaire.

Cette sécurité veut dire que l'on ne peut pas exécuter un syscall à la main (cf Coder le sycall).

Trouver le num d'un syscall​

Avant tout, nous devons faire un test en appelant un syscall. Pour trouver le numéro de syscall de void exit(int num), nous allons lire le man.

$ man 9 syscall

Section Code references on trouve /sys/kern/syscall.master

Ce fichier est très important, il contient la liste des syscalls sur OpenBSD. À noter qu'à la différence de Linux, leurs déclarations sont faites dans ce fichier donc dynamique. Cela fait un des grandes forces de BSD, c'est relativement "simple" d'ajouter un syscall.

Coder le syscall​

En ASM​

.global main
.section .text

main:
  movl $1, %eax;
  syscall;
  ret;

En C​

int main(void) {
  asm volatile ("movl $1, %eax;"
                "syscall;");
  return 0; // Unreached code 
}

Result​

On remarque assez vite que le binaire que nous avons compilé, ne fonctionne pas. main[10291]: pinsyscalls addr 5a288eab978 code 1, pinoff 0xffffffff (pin 330 5a4c881d000-5a4c882b66d e66d) (libcpin 331 5a5145d0000-5a514687000 b7000) error 78 Abort trap (core dumped)

Je suppose que cela doit venir d'un process interne au kernel, qui check la validité de notre appel et qui nous SIGABRT.

Comment fix le syscall ?​

L'idée est de trouver l'endroit qui check le linkage des syscalls dans le kernel et bypass le if.

Dans un premier temps, on cherche dans les man et non pas dans le code. 5 min de lecture peuvent nous éviter beaucoup de recherche dans une codebase.

$ apropos syscall
pinsyscalls(2) - pin system call entry to precise locations in the address space
sqlite3_vfs, sqlite3_syscall_ptr(3) - OS interface object
ktrace, ktrgenio, ktrnamei, KTRPOINT, ktrpsig, ktrsyscall, ktrsysret(9) - process tracing kernel interface
syscall(9) - system calls overview

Nous avons déjà lu le syscall(9) pour trouver notre numéro de syscall, mais pas encore le premier pinsyscalls(2)

pinsyscalls(2)​

On apprend que :

• ld.so(1) cree des entry point pour chaque syscalls
• si on ne respecte pas les entry point alors SIGABRT
• Ca correspond a notre erreur

Trouver pinsyscall​

J'en déduis que l'on cherche ou est pinsyscall(1), trouver le code qui l'appelle puis le fix.

$ cd /usr/src
# Un peu de recherche sur le mode clef syscall plus tard
$ grep -r "PINSYSCALL"
#  ...
lib/libc/arch/amd64/SYS.h:	PINSYSCALL(SYS_ ## x, 97b)

Alors la macro pinsyscall n'est pas défini dans ce fichier (qui est machine-depend). En regardant les include du header, on voit

#include "DEFS.h" // Machine independent
#include  // Machine // independent

Trouver l'utilisation du pinsyscall​

Je découvre que la fonction pinsyscall(1) est défini dans mon fichier DEFS.h. C'est une macro qui génère de l'assembleur. Je ne me lance pas dans l'analyse de son code pour le moment, néanmoins, je garde en tête son existence. Pour le moment, je cherche le code qui check le fonctionnement du pinsyscall.

J'ai vu que le include existe, je vais aller voir par la.

sys/syscall.h​

$ find . -name "syscall.h"
./libexec/ld.so/syscall.h
./sys/arch/riscv64/include/syscall.h
./sys/sys/syscall.h

Deux fichiers ont l'air intéressant celui de ld.so (cf le man que l'on a lu sur les pinsyscall).

Le dossier libexec/ld.so​

Après un rapide grep dans le directory du syscall.h pour trouver qui l'utilise. Je trouve le fichier resolve.c. Cela me permet de découvrir l'implémentation de la fonction pinsyscall et de la struct.

# line 782
struct pinsyscalls {
  u_int offset;
  u_int sysno;
}

Le dossier sys/sys​

grep -r "syscall.h"
syscall.h:/*	$OpenBSD: syscall.h,v 1.282 2025/02/17 13:10:56 mpi Exp $	*/
syscall_mi.h:#include 

The patch​

Nous avons enfin trouvé le fichier qui contient le fameux if qui vérifie la condition d'appels des syscalls. Il nous suffit maintenant de supprimer le else pour ne jamais set le variable error.

$ diff syscall_mi.h.patch syscall_mi.h -Naur > syscall.patch
--- syscall_mi.h	2025-02-20 14:13:12.237060577 +0100
+++ syscall_mi.h.patch	2025-02-20 14:17:23.279746175 +0100
@@ -94,8 +94,7 @@
; /* multiple locations, hopefully a boring operation */
else
error = ENOSYS;
-	} else
-		error = ENOSYS;
+	}
if (error == 0)
return (0);
die:

The Inter-Communication Client Conventions Manual (ICCCM for short), which lays down some rules. The first version was published in July 1989, the second in 1994. This manual, written 30 years ago, is therefore the reference for the subject.

First some history​

X vs X.org vs X11​

The X Window System, also known as X, is old. Written in 1984, it was the default windowing system for most Unix systems. But X is not the implementation, it is more a set of protocols and architecture.

X.org is the free and open source implementation of the X Window System. X.org is also a foundation that oversees the development of X11.

X11 is the latest version (since 1987) of the X architecture, and X10 is the first iteration of the project born with X in 1984.

X10 and cut-buffers​

For context, the first release of X10 was in 1985. At that time, the ICCCM hadn't been released. Xorg was doing its own thing. They used a thing called cut-buffer' or also known as buffer-cut'.

A cut-buffer works like a circular buffer of 8 buffers, ranging from CUTBUFFER0 to CUTBUFFER7. When a user tries to add a string to a cut buffer, each string is swapped to a different buffer. So the circular buffer is like a history of all copy-paste.

Nowadays, there are no more programs that use a cut-buffer, or at least they used the cut-buffer and the new method.

X11 support​

X has an object called 'selections'. It is basically a clipboard, but for a different use. There are THREE selections defined by ICCCM: Primary, Secondary, and Clipboard The ICCCM also makes a distinction between Passive and Active selections.

Passive

When some data is selected, the client handling the window where this selection is done transfers it somewhere, and no longer needs to care about it

Active

Transfer of data to a client requires the client "holding" the selection to actively participate in the exchange.

PRIMARY​

I is mostly used when you select some text with your mouse. You can use your mouse middle click to paste it. I said "mostly" because it depends on the software. Each X11 application decides which binding it uses to interact with a selection.

So, as you understand, it's a `passive' selection. The user does not ask the system to copy this text.

CLIPBOARD​

This is an active selection. It's used when the user wants to copy some data. It can be done with either Ctrl-C or the simpler Mouse right click + copy.

In vim you could copy something with *y and *p or

set clipboard=unnamedplus

So when the user requests Paste, it will be the contents of the CLIPBOARD selection.

SECONDARY​

To be honest, I looked for as much information as I could about this selection, but I couldn't find any application that used it for any good reason.

In vim you could copy something in it with +y and +p.

set clipboard=unnamed

XDND​

Such a complex word, it's just the first letter of X Drag and Drop Protocol. When I did some research on the clipboard, I found information about drag and drop.

When a drag starts, the source takes ownership of XDNDSelection (a structure inside X11), and when the mouse leaves the source, X11 sends a message to the target. At this point the user can release the mouse, the target gets a lot of information with a specific selection XA_PRIMARY. XA stands for XDNDAware, the module responsible for DND in X. With all this information, the target software could easily request the resource from the source software. I learn that within the first iteration of X, there are no optimizations when `target = source'.

Alias​

alias paste="xclip -o"

alias copy="xclip"

And so you can use like this.

cat LONG_FILE | copy 

paste | vim - 

Sources :

• ICCCM
• VimDoc
• ClipbordWiki
• StackOverflow - Diff between X Clip
• XDND

Une magnifique occasion de faire de l'assembleur !

Sans plus attendre, voici notre premier exemple :​

main;

Ce code compile très bien :

gcc main.c -o main

et produit cet output :

$ ./main
[1]    20677 segmentation fault (core dumped)  ./main

Un segfault​

Je pense que c’est le bon moment pour répondre à cette question : c’est quoi un segfault ?

Un segfault ou "segmentation fault" est une erreur de segmentation. On l’obtient lorsque notre programme essaye de lire un pointeur qui ne nous appartient pas.
Au lancement du programme, l’OS lui attribue une certaine quantité de mémoire, et il n’a pas le droit d’en sortir.

C’est une sécurité pour empêcher des programmes d’accéder à des zones mémoire non autorisées.

Quand l’OS (ou plus précisément, le MMU) détecte que le programme tente d’accéder à une mémoire non autorisée, il génère cette "fault".

On dump des objets​

Pour mieux comprendre le fonctionnement du programme, on va aller voir le code machine.
Le flag -t nous permet de récupérer juste la liste des symboles :

$ objdump -t ./main
# <-- truncate --> 
0000000000004000  w      .data	0000000000000000              data_start
0000000000004000 g       .data	0000000000000000              __data_start
0000000000001020 g     F .text	0000000000000026              _start
0000000000004010 g       .bss	0000000000000000              __bss_start
0000000000004014 g     O .bss	0000000000000004              main
# <-- truncate --> 
0000000000001000 g     F .init	0000000000000000              .hidden _init

On remarque que le symbole main est dans le segment .bss et pas dans .text.

Segment bss :​

Le segment .bss (Block Starting Symbol) contient les variables statiques allouées.

Segment text :​

Le segment .text contient les instructions exécutables du programme.

On se rend compte que notre code ne déclare pas une fonction, mais bien une variable. La variable étant globale, le compilateur crée un symbole pour elle.
Cela se vérifie très simplement en rajoutant une variable test dans notre code :

0000000000004018 g     O .bss	0000000000000004              test

En effet, le nom main n’est pas un keyword spécifique en C. C’est juste un nom de fonction arbitraire qui est appelé au lancement du programme.

Pour les Québécois​

Pour les puristes d’entre vous, il est tout à fait possible de ne pas inclure une fonction main dans votre code.
Il suffit d’écrire votre propre fonction _start et de demander à GCC de ne pas linker la sienne :

#include <stdio.h>
#include <stdlib.h>

int principale() {
  puts("Hey là, ça marche-tu?");
  return 0;
}

void _start() {
  int ret = principale();
  exit(ret);
}

$ gcc principale.c -o principale -nostartfiles

Lancement du programme​

Mais au fait, qui call la fonction main ?

Pour répondre à cette question, regardons le code assembleur de notre programme, en particulier la fonction _start.
Au passage, on remarque que son symbole est bien dans le segment .text.

Voici une version simplifiée du code (la fonction complète est assez complexe) :

_start: 
    xor %ebp, %ebp            
    mov (%rsp), %edi          
    lea 8(%rsp), %rsi         
    lea 16(%rsp,%rdi,8), %rdx 
    xor %eax, %eax            
    call main                 

    mov %eax, %edi    
    xor %eax, %eax   
    call _exit      

Étapes de _start :​

• On marque la fin de la stack frame :
  xor %ebp, %ebp
• On initialise argc :
  mov (%rsp), %edi
• On initialise argv :
  lea 8(%rsp), %rsi
• On initialise envp :
  lea 16(%rsp,%rdi,8), %rdx
• On set un code retour initialisé à 0 (compatibilité) :
  xor %eax, %eax
• On call main(argc, argv, envp) :
  call main
• On call la fonction _exit avec le code retour :
  mov %eax, %edi
call _exit

Envp ??​

Le vrai prototype de la fonction main a 3 arguments :

int main(int argc, char* argv[], char* envp[]);

Oui, j’ai découvert le vrai prototype en analysant le reverse de _start.

Comme son nom l’indique, envp correspond aux variables d’environnement du shell.
Si on ne vous a jamais montré ça, c’est parce que ce n’est pas portable (même si toutes les machines actuelles le supportent).

Encore plus petit​

Et oui, si vous avez bien suivi, il est maintenant possible de segfault encore plus vite. Il suffit que le segfault soit directement dans la fonction _start, sans passer par main.

Voici un exemple minimaliste (vide) :

$ touch main.c
/usr/bin/ld: warning: cannot find entry symbol _start; defaulting to 0000000000001000
$ gcc -o main main.c -nostartfiles

Nous avons certes un warning, mais ça compile.
Un objdump montre qu’il n’y a presque rien dans ce fichier et que le symbole _start n’est pas défini :

$ objdump -t ./main
<-- truncate --> 
0000000000000000         *UND*	0000000000000000 _start

Scrt1.o, ça sort d'où ?​

Alors hormis le fait que j'ai lu la doc de GCC, comment est-ce que je sais que Scrt1.o existe ?
Vous connaissez le -v ? Eh oui, on peut très bien activer le debug / verbose sur GCC.

Personne ne le fait parce qu'il faut avoir un sacré melon pour considérer que GCC fait mal son travail (sauf moi).

En activant ce flag, on se retrouve avec pas mal de variables d'env qui sont print, mais pas que. On trouve notamment cette ligne dans laquelle on voit l'include des fichiers .o :

/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/collect2 
    -plugin /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/liblto_plugin.so 
    -plugin-opt=/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/lto-wrapper 
    -plugin-opt=-fresolution=/tmp/ccEcycpv.res 
    -plugin-opt=-pass-through=-lgcc 
    -plugin-opt=-pass-through=-lgcc_s 
    -plugin-opt=-pass-through=-lc 
    -plugin-opt=-pass-through=-lgcc 
    -plugin-opt=-pass-through=-lgcc_s 
    --build-id --eh-frame-hdr --hash-style=gnu 
    -m elf_x86_64 
    -dynamic-linker /lib64/ld-linux-x86-64.so.2 
    -pie -o main 
    /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/../../../../lib/Scrt1.o 
    /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/../../../../lib/crti.o 
    /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/crtbeginS.o 
    -L/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1 
    -L/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/../../../../lib -L/lib/../lib -L/usr/lib/../lib 
    -L/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/../../.. /tmp/cciOyF1Z.o 
    -lgcc 
    --push-state 
    --as-needed 
    -lgcc_s --pop-state -lc -lgcc --push-state --as-needed -lgcc_s 
    --pop-state /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/crtendS.o 
    /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/../../../../lib/crtn.o

On remarque beaucoup de flags, on peut essayer d'analyser rapidement leur effet.

• Les amateurs de CTF, vous aurez remarqué le flag -pie, qui permet d'activer l'Address Space Layout Randomization (ASLR).
• -lgcc : eh oui, votre programme C compile avec la librairie dynamique GCC.
  Vous pouvez éviter ça en compilant avec -nostdlib. Je ne vois pas bien l'intérêt, mais c'est un choix.
• -m elf_x86_64 : c'est ici que GCC spécifie l'architecture de la machine cible.
  C'est possible de modifier cette machine cible, cela s'appelle la cross compilation (mais j'en ferai un article spécifique).

On trouve aussi le fichier Scrt1.o, qui contient le point d'entrée (_start) de l'exécutable. Les fichiers crti.o et crtbeginS.o, eux, fournissent des routines nécessaires à l’initialisation des fonctions globales et statiques.
On pourra citer les fonctions _init et _fini.

Source :

• The C Runtime Initialization, crt0.o
• Linux Questions - Forums
• Stackoverflow - _start in C

Bonus​

Pour les chads ! Voici le code complet de la fonction _start.

0000000000001020 <_start>:
    1020:	f3 0f 1e fa          	endbr64
    1024:	31 ed                	xor    %ebp,%ebp
    1026:	49 89 d1             	mov    %rdx,%r9
    1029:	5e                   	pop    %rsi
    102a:	48 89 e2             	mov    %rsp,%rdx
    102d:	48 83 e4 f0          	and    $0xfffffffffffffff0,%rsp
    1031:	50                   	push   %rax
    1032:	54                   	push   %rsp
    1033:	45 31 c0             	xor    %r8d,%r8d
    1036:	31 c9                	xor    %ecx,%ecx
    1038:	48 8d 3d d5 2f 00 00 	lea    0x2fd5(%rip),%rdi        # 4014 <main>
    103f:	ff 15 7b 2f 00 00    	call   *0x2f7b(%rip)        # 3fc0 <__libc_start_main@GLIBC_2.34>
    1045:	f4                   	hlt
    1046:	66 2e 0f 1f 84 00 00 	cs nopw 0x0(%rax,%rax,1)
    104d:	00 00 00
    1050:	48 8d 3d b9 2f 00 00 	lea    0x2fb9(%rip),%rdi        # 4010 <__TMC_END__>
    1057:	48 8d 05 b2 2f 00 00 	lea    0x2fb2(%rip),%rax        # 4010 <__TMC_END__>
    105e:	48 39 f8             	cmp    %rdi,%rax
    1061:	74 15                	je     1078 <_start+0x58>
    1063:	48 8b 05 5e 2f 00 00 	mov    0x2f5e(%rip),%rax        # 3fc8 <_ITM_deregisterTMCloneTable@Base>
    106a:	48 85 c0             	test   %rax,%rax
    106d:	74 09                	je     1078 <_start+0x58>
    106f:	ff e0                	jmp    *%rax
    1071:	0f 1f 80 00 00 00 00 	nopl   0x0(%rax)
    1078:	c3                   	ret
    1079:	0f 1f 80 00 00 00 00 	nopl   0x0(%rax)
    1080:	48 8d 3d 89 2f 00 00 	lea    0x2f89(%rip),%rdi        # 4010 <__TMC_END__>
    1087:	48 8d 35 82 2f 00 00 	lea    0x2f82(%rip),%rsi        # 4010 <__TMC_END__>
    108e:	48 29 fe             	sub    %rdi,%rsi
    1091:	48 89 f0             	mov    %rsi,%rax
    1094:	48 c1 ee 3f          	shr    $0x3f,%rsi
    1098:	48 c1 f8 03          	sar    $0x3,%rax
    109c:	48 01 c6             	add    %rax,%rsi
    109f:	48 d1 fe             	sar    $1,%rsi
    10a2:	74 14                	je     10b8 <_start+0x98>
    10a4:	48 8b 05 2d 2f 00 00 	mov    0x2f2d(%rip),%rax        # 3fd8 <_ITM_registerTMCloneTable@Base>
    10ab:	48 85 c0             	test   %rax,%rax
    10ae:	74 08                	je     10b8 <_start+0x98>
    10b0:	ff e0                	jmp    *%rax
    10b2:	66 0f 1f 44 00 00    	nopw   0x0(%rax,%rax,1)
    10b8:	c3                   	ret
    10b9:	0f 1f 80 00 00 00 00 	nopl   0x0(%rax)
    10c0:	f3 0f 1e fa          	endbr64
    10c4:	80 3d 45 2f 00 00 00 	cmpb   $0x0,0x2f45(%rip)        # 4010 <__TMC_END__>
    10cb:	75 33                	jne    1100 <_start+0xe0>
    10cd:	55                   	push   %rbp
    10ce:	48 83 3d 0a 2f 00 00 	cmpq   $0x0,0x2f0a(%rip)        # 3fe0 <__cxa_finalize@GLIBC_2.2.5>
    10d5:	00
    10d6:	48 89 e5             	mov    %rsp,%rbp
    10d9:	74 0d                	je     10e8 <_start+0xc8>
    10db:	48 8b 3d 26 2f 00 00 	mov    0x2f26(%rip),%rdi        # 4008 <__dso_handle>
    10e2:	ff 15 f8 2e 00 00    	call   *0x2ef8(%rip)        # 3fe0 <__cxa_finalize@GLIBC_2.2.5>
    10e8:	e8 63 ff ff ff       	call   1050 <_start+0x30>
    10ed:	c6 05 1c 2f 00 00 01 	movb   $0x1,0x2f1c(%rip)        # 4010 <__TMC_END__>
    10f4:	5d                   	pop    %rbp
    10f5:	c3                   	ret
    10f6:	66 2e 0f 1f 84 00 00 	cs nopw 0x0(%rax,%rax,1)
    10fd:	00 00 00
    1100:	c3                   	ret
    1101:	66 66 2e 0f 1f 84 00 	data16 cs nopw 0x0(%rax,%rax,1)
    1108:	00 00 00 00
    110c:	0f 1f 40 00          	nopl   0x0(%rax)
    1110:	f3 0f 1e fa          	endbr64
    1114:	e9 67 ff ff ff       	jmp    1080 <_start+0x60>

Histoire​

Mais d'abord, comme à mon habitude, un petit point histoire.

En 1999, Kent Beck a approfondi le sujet dans son premier livre sur l'Extreme Programming. En 2001, CruiseControl, l'un des premiers outils open-source de CI, a vu le jour.

Mais why ?​

Le but d'une CI est de faire des tests automatisés à chaque commit. Cela garantit que le code reste fonctionnel en permanence. On appelle cela une Continuous Integration car, à chaque modification, le code est vérifié pour s'assurer qu'il n'y a pas de régressions.

Avantages​

• Détection précoce des erreurs : Les problèmes sont identifiés rapidement, ce qui permet de réagir sans attendre.
• Amélioration de la qualité : En testant systématiquement, on garantit un code plus robuste.
• Gain de temps : Les pipelines automatisés réduisent la nécessité de tests manuels répétitifs.

Inconvénients​

• Coût initial : Mettre en place une CI peut demander des efforts et des compétences initiales importantes.
• Temps d’exécution : Les pipelines complexes peuvent rallonger le temps avant qu'un développeur puisse valider son code.

Fonctionnement​

Avant de voir le fonctionnement, un petit lexique :

• Jobs : Une instance d'un conteneur (souvent Docker) qui exécute un script. Cela peut inclure des commandes, des tests ou des actions simples comme un echo.
• Pipeline : Une série de jobs organisés de manière séquentielle ou parallèle. Chaque commit déclenche cette série pour valider les changements.

Le principe est simple : chaque job retourne un code de statut (succès ou échec). Si un job échoue, la pipeline s’arrête ou ignore les étapes suivantes selon la configuration.

Trêve de blabla​

Nous allons utiliser un exemple basé sur GitLab CI. On la configure via un fichier .gitlab-ci.yml.

Basique, simple, simple, basique​

image: bookworm-slim:latest

myjobname:
  script:
    - make

Les flags​

Pour ajouter des flags de compilation, deux approches sont possibles :

1. Via une règle dans le Makefile.
2. En passant les flags directement dans la commande CI.

myjobname_hard:
  script:
    - CFLAGS="-Wall -Werror" make
    # ou
    - make compile_flags

Tests avec Criterion et flags​

Criterion est une bibliothèque de tests unitaires en C.

Où est passé Criterion ?​

Avant d’exécuter des tests avec Criterion, il est souvent nécessaire d'installer Criterion, eh oui !

before_script:
  - apt-get update && apt-get install -y libcriterion-dev
script:
  - ./configure
  - make test

Multistaging​

Diviser les tests unitaires et fonctionnels en plusieurs stages garantit :

• une bonne organisation
• une meilleure visibilité des résultats

stages:
  - build
  - test

build:
  stage: build
  script:
    - make all

test-unit:
  stage: test
  script:
    - make unit-test

test-functional:
  stage: test
  script:
    - make functional-test

Tu t'es fait clang ?​

Le formatage du code est super important pour maintenir une base de code propre.

clang_format:
  stage: format
  before_script:
    - apt-get -qq update && apt-get -qq install -y clang-format autotools-dev autoconf-archive gcovr libcriterion-dev
  script:
    - clang-format -i $(find src/ -type f -name "*.c") --dry-run --Werror

Cache​

Dans certains cas, c'est utile de mettre en cache des fichiers ou dossiers pour éviter de les recharger à chaque pipeline.
Un exemple courant est le dossier node_modules/ en JavaScript.

cache:
  paths:
    - node_modules/

install:
  script:
    - npm install

Bien entendu, vous pouvez nettoyer le cache au besoin avec une option supplémentaire dans la configuration de pipeline.

Artefacts​

Les artefacts sont les fichiers générés par la CI qui peuvent être partagés entre jobs ou téléchargés.
Par exemple, les rapports de tests ou de couverture.

artifacts:
  paths:
    - build/
    - reports/

Coverage de tests​

On peut mesurer la couverture de tests en intégrant des outils comme gcovr ou Cobertura dans votre pipeline CI.

test-coverage:
  stage: test
  script:
    - gcovr --html --html-details -o coverage.html
  artifacts:
    paths:
      - coverage.html

Rapporteur​

Ce bloc vous permet d'intégrer le coverage report dans votre Merge Request, vous pourrez ainsi voir le code qui n'est pas couvert mais aussi votre pourcentage de coverage.

coverage-report:
  script:
    # do coverage
  coverage: /^TOTAL.*\s+(\d+\%)$/
  artifacts:
    name: coverage.xml
    expire_in: 2 days
    reports:
      coverage_report:
        coverage_format: cobertura
        path: coverage.xml

Environnement custom​

Vous pouvez préciser l’environnement de base pour votre CI en sélectionnant une image Docker spécifique.

image: gcc:latest

En utilisant un peu ce que l'on vient de voir, ça donnerait quelque chose comme ça :

image: gcc

stages:
  - format
  - build
  - test
  - clean

clang-format:
  stage: format
  script:
    - clang-format -i $(find src/ -type f -name "*.c") --dry-run --Werror

build:
  stage: build
  script:
    - autoreconf --install
    - ./configure
    - make all

test-unit:
  stage: test
  script:
    - autoreconf --install
    - ./configure
    - make unit-test

Attention aux .h et il manque des before_script.

Petit Bonus​

On peut aussi vérifier les trash-files pour s’assurer que le make clean fait bien son travail.

trash-file:
  stage: clean
  needs: []
  before_script:
    - apt-get -qq update && apt-get -qq install -y tree
  script:
    - tree > /tmp/REF
    - make && make clean
    - tree > /tmp/TEST
    - diff /tmp/REF /tmp/TEST

Conclusion​

La Continuous Integration est un outil extrêmement puissant. Il peut parfois être difficile à mettre en place, mais les gains sont immenses.

Dans ce cas pratique, nous allons utiliser Proxmox et BPG. Il existe deux principaux providers pour Proxmox :

• Telmate
  C’est une bibliothèque qui permet de déployer très simplement des VMs et des LXCs.
  Inconvénient : elle n’implémente pas de fonctionnalités avancées. Cependant, elle est fréquemment mise à jour.

• Bpg
  Cette bibliothèque est légèrement plus complexe à prendre en main, mais elle est bien plus puissante.

Organisation et Structure d'un Projet Terraform​

Afin que vous puissiez mieux comprendre le projet, voici son architecture :

├── main.tf
├── provider.tf
├── variable.tf
└── terraform.auto.tfvars

Vous pouvez ajouter ou segmenter le projet en autant de fichiers .tf que nécessaire. Par exemple, nous aurions pu avoir un fichier pour les VMs et un autre pour les LXCs.

• Les fichiers se terminant par .tfvars servent à définir des variables. Lorsqu’ils commencent par auto, ils sont automatiquement chargés par Terraform.
• Le fichier variable.tf permet de créer des variables sans les instancier.

Petit point Vocabulaire​

Dans cette article, nous allons utiliser le terme de LXC et de VM. Je vais faire un petit point dessus.

• LXC ou LinuX Container : ce sont des environnements virtualisés qui tourne sur le kernel de l'hôte mais qui ne peuvent pas discuter ensemble. Cela permet de segmenter nos services sans trop perde en performance.

• VM ou Virtual Machine : comme son nom l'indique, on simule l'intégralité d'une machine. On perd en performance mais on gagne en sécurité et en fonctionnalité car un LXC n'a pas tout les privilèges.

Choisir et Configurer un Provider Proxmox​

Avant tout, nous devons installer le provider (la bibliothèque). Bien entendu, nous fixons une version minimale :

terraform {
  required_providers {
    proxmox = {
      source  = "bpg/proxmox"
      version = ">= 0.3.0"
    }
  }
  required_version = ">= 0.14"
}

Une fois la bibliothèque ajoutée, nous déclarons un provider nommé "proxmox", en fournissant les informations nécessaires :

provider "proxmox" {
  endpoint = "https://${var.proxmox_endpoint}:8006"
  api_token = var.api_token_secret

  insecure = true # car un certificat TLS auto-signé est utilisé
  ssh {
    agent = true
    username = terraform
  }
}

Les Variables dans Terraform​

Si vous êtes attentif, vous avez remarqué que nous utilisons l’objet var.api_token_secret dans le bloc du provider. Cette chaîne de caractères est définie dans le fichier terraform.auto.tfvars.

À la manière d’un fichier .env, ce fichier contient des valeurs sensibles et ne doit pas être poussé sur le dépôt git :

# terraform.auto.tfvars
api_token_secret = "terraform-prov@pve!terraform=TOKEN"

Dans le fichier variable.tf, nous définissons les variables et leur type.
Voici les principaux types disponibles :

• number
• string
• list() (ex. : list(string))
• object
• map

Exemple :

# variable.tf

variable "api_token_secret" {
  description = "Secret token to connect Proxmox API"
  type        = string
}

variable "proxmox_endpoint" {
  description = "The domain name of the Proxmox instance"
  type        = string
  default     = "proxmox.mysite.fr"
}

Les Images et les Templates​

Pour démarrer nos entités, nous devons leur fournir un système d’exploitation.
Nous téléchargeons automatiquement un fichier de template pour le LXC et un ISO avec cloud-init pour la VM.

Si vous ne connaissez pas cloud-init, c’est une méthode permettant d’instancier des machines sans passer par l’installateur de l’OS.

resource "proxmox_virtual_environment_download_file" "ubuntu_22-04_lxc" {
  content_type = "vztmpl"
  datastore_id = "local"
  node_name    = var.target_node
  url          = "http://download.proxmox.com/images/system/ubuntu-22.04-standard_22.04-1_amd64.tar.zst"
}

resource "proxmox_virtual_environment_download_file" "ubuntu_22-04_img" {
  content_type = "iso"
  datastore_id = "local"
  node_name    = var.target_node
  url          = "https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64.img"
}

On crée un Réseau Virtuel​

Si nous avons envie que nos ressources discutent entre elles, il nous faut un réseau.

Pour créer un adaptateur virtuel, il suffit d’appeler la ressource proxmox_virtual_environment_network_linux_bridge et de lui donner un nom :

resource "proxmox_virtual_environment_network_linux_bridge" "internal_network" {
  node_name = var.target_node
  name      = "vmbr5"
  comment   = "Internal Network"
}

Votre premier Container​

Passons aux choses concrètes en instanciant un LXC. Pour cela, nous créons une ressource proxmox_virtual_environment_container.

Avec l’IaC, tout peut être configuré : le disque, la RAM, le serveur DNS, etc.

resource "proxmox_virtual_environment_container" "first_lxc" {
  description   = "Managed by Terraform - Mr.VyM"
  node_name     = var.target_node
  start_on_boot = true
  started       = true

  vm_id = 101

  cpu {
    architecture = "amd64"
    cores        = var.core_nb
  }

  disk {
    datastore_id = "storage"
    size         = var.disk_size
  }

  memory {
    dedicated = var.memory_size
    swap      = 0
  }

  operating_system {
    template_file_id = proxmox_virtual_environment_download_file.ubuntu_22-04_lxc.id
    type             = "ubuntu"
  }

  initialization {
    hostname = "mycontainer"

    dns {
      servers = ["1.1.1.1", "1.0.0.1"]
    }

    ip_config {
      ipv4 {
        address = "192.168.10.2/24"
        gateway = "192.168.10.1"
      }
    }

    user_account {
      keys     = ["keys 1", "keys 2"]
      password = var.lxc_password
    }
  }

  network_interface {
    bridge = proxmox_virtual_environment_network_linux_bridge.internal_network.name
    name   = "eth0"
  }
}

Et maintenant une VM​

Créer une VM suit le même pattern que pour un LXC, avec quelques différences :

resource "proxmox_virtual_environment_vm" "vm_template" {
  description = "Managed by Terraform - Mr.VyM"
  node_name   = var.target_node

  name        = "MyDummyVM"
  vm_id       = 102

  cpu {
    cores = var.core_nb
    type  = "x86-64-v2-AES"  # recommandé pour les CPU modernes
  }

  memory {
    dedicated = var.memory_size
    floating  = var.memory_size # active le ballooning
  }

  disk {
    datastore_id = "local"
    file_id      = proxmox_virtual_environment_download_file.ubuntu_22-04_img.id
    interface    = "scsi0"
    size         = var.disk_size
  }

  initialization {
    ip_config {
      ipv4 {
        address = "${var.base_subnet}.3/24"
        gateway = "${var.base_subnet}.1"
      }
    }

    user_account {
      keys     = ["keys 1", "keys 2"]
      password = var.vm_password 
      username = "mrvym"
    }

    datastore_id = "local"
  }

  network_device {
    bridge = proxmox_virtual_environment_network_linux_bridge.internal_network.name
  }

  operating_system {
    type = "l26" # Linux Kernel
  }
}

On check et ca part en Prod​

Enfin, nous déployons le tout avec les commandes suivantes :

• terraform init
  Initialise Terraform, télécharge les providers et crée les fichiers terraform.state et terraform.lock. Ces fichiers stockent l’état des entités sur le serveur.
  Si ces fichiers sont absents, Terraform recrée les ressources, ce qui pourrait entraîner leur suppression et recréation.

• terraform fmt
  Formate le code pour garantir sa propreté.

• terraform plan
  Vérifie les actions que Terraform s’apprête à exécuter.

• terraform apply
  Applique les modifications.

Ecrit pour l'Avent of Tech de la JECT

Mais d'abord, un "rapide" récapitulatif de l'état actuel de nos périphériques de stockage :

Si vous vous demandez, oui, les constructeurs ont pris un malin plaisir à utiliser le même nom entre l'interface et la norme.

-- Avant de commencer, un point vocabulaire

Couche Physique : C'est le cable et le connecteur.

Interface Materielle : C'est la maniere de communiquer, attention ne pas confondre avec le "language".

Jeu de commandes : C'est le language utilisé.

Pour faire une analogie, si vous etes un humain (j'espere 🤔), la couche physique c'est vos cordes vocales, l'interface materielle, c'est la maniere de faire vibrer vos cordes et le jeu de commandes, c'est le language utilisé.

Norme de stockage​

ATA​

Date : 1986
Qui : Western Digital

ATA signifie Advanced Technology Attachment.

C'est le véritable concurrent du protocole SCSI. C'est aussi un ensemble de normes avec l'interface matérielle (IDE), la couche physique (PATA ou bien SATA) et les jeux de commandes (ACS).

C'est une version plus low-cost de SCSI, qui avait pour but de réutiliser des éléments de ce dernier mais en simplifiant le connecteur (la couche physique) et le jeu d'instruction.

Contrairement au SAS, cette norme est en semi-duplex, ce qui signifie qu'elle ne peut exécuter qu'une seule action simultanément : soit lire, soit écrire.

SAS​

Date : 1980
Qui : Shugart / NCR Corporation

C'est un ensemble de normes qui s'applique sur les couches physiques et les jeux de commandes.

Nous devons revenir dans les années 80, à cette époque, il n'y a pas des milliers de façons de communiquer avec un périphérique de stockage. L'un d'entre eux est le protocole SCSI (Small Computer System Interface).

C'est un protocole propriétaire mais très performant pour son temps. Son grand avantage est le fait de déporter la logique dans le périphérique, contrairement à ses concurrents qui utilisent allègrement la puissance de l'ordinateur. Et dans les années 80, on n'avait pas encore la puissance de calcul, ce protocole a donc été particulièrement apprécié par l'industrie.

De plus, la norme a l'avantage de pouvoir écrire en duplex, c'est-à-dire lire et écrire des données simultanément.

Interface matérielle​

IDE​

IDE est une norme qui intègre le contrôleur de disque directement sur le disque dur lui-même. Avant IDE, les contrôleurs de disque étaient séparés, ce qui compliquait la configuration et limitait la compatibilité.
Cela signifie qu'un disque dur est dit compatible IDE s'il possède une puce IDE.

SATA​

C'est une ré-implémentation de l'interface matérielle parallèle en série (Serial ATA).

Qu'est-ce qu'un port parallèle ?
Contrairement au port série, un port parallèle peut transférer un ensemble de 8 bits à la fois sur huit fils différents.

Pour vous donner une idée de l'interface matérielle / couche physique.

PCIe​

L'interface matérielle PCIe (Peripheral Component Interconnect Express) est une interface de communication utilisée principalement pour connecter des périphériques internes tels que des cartes graphiques, des cartes réseau et d'autres cartes d'extension.

Elle utilise un bus série, ce qui signifie que les données sont transmises bit par bit sur une seule ligne, contrairement aux anciennes interfaces parallèles.

PCIe fonctionne avec des connecteurs spécifiques et des voies de transmission (lanes) qui permettent des transferts de données très rapides.

Les cartes PCIe sont insérées dans des slots PCIe sur la carte mère, et l'interface est disponible en différentes versions (x1, x4, x8, x16) en fonction du nombre de voies utilisées, offrant ainsi une bande passante ajustée aux besoins des périphériques.

PCIe est largement utilisé dans les systèmes modernes en raison de sa vitesse de transmission élevée, de sa flexibilité et de sa capacité à évoluer pour prendre en charge des dispositifs nécessitant des débits importants.

Couche physique​

Globalement, c'est la partie la plus simple de l'article.
(Enfin, en électronique, ce n'est jamais simple).

Une couche physique, cela signifie que c'est la norme qui régit la façon de réaliser le câble et le connecteur (cf Illustration du Pin-out)

Une nappe IDE Dans notre cas, c'est un câble dit "IDE".
Ce genre de câble est la version parallèle, il contient 80 fils, ce qui permet de connecter deux appareils à la carte mère. Le premier sera appelé "master" et le deuxième "slave".

Mais je ne vais pas détailler les différents câbles qui existent.

Jeux de commandes​

ACS (Commandes)​

Date : années 80
Qui : Shugart / NCR Corporation

Le ATA Command Set (ACS) est la liste des commandes que le système peut envoyer au périphérique.
On pourrait citer comme exemples :

• WRITE_SECTOR
• SLEEP
• PACKET
• IDENTIFY PACKET DEVICE

SCSI​

ACS étant un détournement du jeu de SCSI, on retrouve de grandes similitudes entre les deux jeux. Cependant, on peut les différencier en creusant un peu, notamment en ce qui concerne les rapports d'erreurs.

AHCI​

AHCI (Advanced Host Controller Interface) permet une communication optimisée entre le système d'exploitation et les périphériques de stockage, en offrant des fonctionnalités avancées comme le contrôle de file d'attente (pour améliorer les lectures/écritures simultanées) et le mode NCQ (Native Command Queuing), qui permet au disque de réorganiser les commandes d'entrée/sortie pour une performance maximale.

Ce jeu de commandes facilite également des fonctionnalités telles que la gestion de l'alimentation et le hot-plug (permettre l'ajout et le retrait de périphériques sans éteindre le système).

AHCI a été conçu pour améliorer les performances et la gestion des périphériques de stockage SATA en optimisant l'utilisation des ressources et la vitesse des transferts.

Conclusion / Performance

Nous n'avons toujours pas parlé de la partie performance de ces différences, donc voici le mot de la fin.

En C, les lignes qui commencent par un # sont interprétées par le compilateur lors de la compilation des fichiers sources. On les appelle des directives du préprocesseur. Les macros en font partie.

Petit point historique :

Les macros en langage C ont été introduites avec la première norme du langage C, appelée ANSI C (ou C89), qui a été standardisée par l'American National Standards Institute (ANSI) en 1989.

Cependant, avant cette standardisation, les macros faisaient déjà partie du langage C classique (ou K&R C) utilisé dans les années 1970. Le compilateur C original, développé par Dennis Ritchie pour le système d'exploitation UNIX, incluait déjà une forme rudimentaire de macros via le préprocesseur, permettant des définitions avec #define.

Define

#define SENS_DE_LA_VIE 3.14

/* ... */

printf("%f\n", SENS_DE_LA_VIE);

Le define a un fonctionnement assez simple à comprendre : le compilateur remplace toutes les occurrences dans le code par la valeur définie. Il fonctionne avec la syntaxe suivante #define <MACRO_NAME> <value>. On a pour convention de mettre le nom en majuscule, la valeur quant à elle est optionnelle.

Un peu comme un "Ctrl-f et remplacer".

Mama, la macro​

On peut utiliser les define pour définir des fonctions que l'on pourra utiliser dans notre code.

#define INC(a) a++ 
#define MULTI_LINE(a,b) a = b; \
                        b = 0; 


INC(my_variable); 
MULTI_LINE(my_variable, foobar) 
// Je souligne le fait qu'il peut ne pas y avoir de ';' en fin de ligne 

// Cela donnera  
my_variable++;
my_variable = foobar;
foobar = 0;

If or not if​

Nous pouvons déclarer des macros de manière conditionnelle. Si un nom est déjà défini alors on exécute le bout de code suivant.

#ifdef DEBUG
// Je souligne qu'il est rarement conseillé d'utiliser des printf() en debug
// et que nous avons brisé la règle du nom des macros en MAJ.
#define return printf("(%s:%d)\n", __FUNCTION__, __LINE__);  return
#endif /* ! DEBUG */

int main(void) {
    return 1;
}

Dans ce cas, j'utilise un #ifndef, mais il existe aussi :

• #ifdef
• #if
• #else
• #elif

#if (X == 1)
#define Y 2
#elif (X == 2)
#define Y "Ami de la bonne blague, bonjour !"
#else
#define Y NULL
#endif /* ! X */

/* ... */

int main(void) {
    #if (X == 1)
    printf("%d\n", Y);
    #else 
    printf("%s\n", Y);
    #endif /* ! X */
}

On aime bien signaler avec un commentaire en bloc la fin des #if. C'est une convention qui permet de mieux se repérer dans le code.

Macros prédéfinies​

Vous avez pu voir dans l'exemple précédent que j'utilisais les mots-clés __FUNCTION__ et __LINE__. Comme vous pouvez vous en douter, ce sont des macros que le compilateur va remplacer par la bonne valeur.

Il existe une liste de macros prédéfinies Common Predifined.

À noter qu'il existe des macros dites System specific.

Petite liste non exhaustive :

• __DATE__ : Jan 14 2012
• __GNUC__ : Version majeure de GCC
• __TIME__ : 15:12:18
• __INCLUDE_LEVEL__ : La profondeur des includes en commençant par 0
• __BASE_FILE__ : Le nom du fichier actuel

Vers l'infini et au-delà des arguments​

// Ici, l'opérateur ## est l'opérateur de concaténation
#define DEBUG_PRNTF(fmt, ...) printf("LOG" ## fmt, __VA_ARGS__);

Ici, on peut voir que l'on génère des macros variadiques, surtout utiles lors de la création de logs. (Même si ce n'est pas une bonne idée de faire des logs avec des printf.)

X-Macro​

Pour cela, nous allons devoir créer un fichier externe, souvent nommé en *.def bien qu'il n'existe pas de convention.

// color.def
X(NC, "\e[0m", "No Color", 0x000000) 
X(BLACK, "\e[0;30m", "Black", 0x000000) 
X(GRAY, "\e[1;30m", "Gray", 0x808080) 
X(RED, "\e[0;31m", "Red", 0xFF0000) 
X(LIGHT_RED, "\e[1;31m", "Light Red", 0xFF8080) 
X(GREEN, "\e[0;32m", "Green", 0x00FF00) 
X(LIGHT_GREEN, "\e[1;32m", "Light Green", 0x80FF80) 
X(BROWN, "\e[0;33m", "Brown", 0xA52A2A) 
X(YELLOW, "\e[1;33m", "Yellow", 0xFFFF00) 
X(BLUE, "\e[0;34m", "Blue", 0x0000FF) 
X(LIGHT_BLUE, "\e[1;34m", "Light Blue", 0xADD8E6) 
X(PURPLE, "\e[0;35m", "Purple", 0x800080) 
X(LIGHT_PURPLE, "\e[1;35m", "Light Purple", 0xEE82EE) 
X(CYAN, "\e[0;36m", "Cyan", 0x00FFFF) 
X(LIGHT_CYAN, "\e[1;36m", "Light Cyan", 0xE0FFFF) 
X(LIGHT_GRAY, "\e[0;37m", "Light Gray", 0xD3D3D3) 
X(WHITE, "\e[1;37m", "White", 0xFFFFFF)

typedef struct {
    const char *name;        
    const char *ansi_code;  
    const char *description;
    unsigned int rgb;      
} Color;

#define X(NAME, ANSI, DESC, RGB) { #NAME, ANSI, DESC, RGB },
Color colors[] = {
    #include "color.def"
};
#undef X

#define X(NAME, ANSI, DESC, RGB) printf("%s (%s) = %s\n", #NAME, DESC, #RGB);
void print_colors() {
    // Bien entendu, on pourrait itérer sur la structure créée mais c'est une illustration
    #include "color.def"
}
#undef X

Ce genre de macro est extrêmement utile. Je dois reconnaître qu'on la retrouve rarement dans un code source, mais elle permet de modifier le fonctionnement du programme sans pour autant devoir modifier le code source. Fun fact, elle est souvent utilisée dans la création de kernels. Elle permet de générer les structures globales comme l'IDT et la GDT.

Les problèmes​

Attention : Petite mise au point d'abord, les macros sont des outils formidables mais il faut faire attention. Vous ne devez surtout pas utiliser ce genre de macro :

#define MIN(a,b) (a < b ? a : b)

Prenons un exemple : MIN(2 + 5, fibo(25))

Problème n°1​

MIN(2 + 5, fibo(25)) => (2 + 5 < fibo(25) ? 2 + 5 : fibo(25))

Ici le problème est la priorité de calcul. Le compilateur va d'abord effectuer la comparaison puis l'addition, donc 2 + (1). On corrige cela par l'ajout de parenthèses en utilisant les arguments des macros.

#define MIN(a,b) ((a) < (b) ? (a) : (b))

Comme vous ne savez jamais ce que vos utilisateurs vont passer en paramètre, mettez toujours des parenthèses sur les arguments.

Problème n°2​

MIN(2 + 5, fibo(25)) => (2 + 5 < fibo(25) ? 2 + 5 : fibo(25))

On remarque que le compilateur fait un remplacement bête et méchant, ce qui veut dire que l'on va calculer deux fois fibo(25). Je vous laisse imaginer si c'est une implémentation récursive.

Pour fixer ce problème, nous déclarons une variable intermédiaire avant le if.

Macros utiles​

#define MIN(a, b)                                                              \
    ({                                                                         \
        __typeof__(a) _a = a;                                                  \
        __typeof__(b) _b = b;                                                  \
        (_a) > (_b) ? (_b) : (_a);                                             \
    })

#define ABS(a)                                                                 \
    ({                                                                         \
        __typeof__(a) _a = a;                                                  \
        0 < (_a) ? (_a) : -(_a);                                               \
    })

#define MAX(a, b)                                                              \
    ({                                                                         \
        __typeof__(a) _a = a;                                                  \
        __typeof__(b) _b = b;                                                  \
        (_a) < (_b) ? (_b) : (_a);                                             \
    })

#define CLAMP(a, x, b) MAX(a, MIN(x, b))
// Pour les tableaux uniquement
#define COUNT_OF(arr) sizeof(arr) / sizeof(arr[0])

Là, on s'amuse​

Ici, c'est du code purement overkill juste pour le fun. Je ne vous conseille pas forcément d'utiliser ces macros dans votre code. Je me fais juste plaisir (faut bien dans la vie).

Un auto free​

#define DEFER(free_call) __attribute__((cleanup(free_call)))

void auto_free(void *ptr) {
    void **p = (void **)ptr;
    if (*p) {
        free(*p);
        *p = NULL;
    }
}

int main() {
  DEFER(auto_free) char* buffer = malloc(10);
  return 0;
}

Je vous laisse tester avec un petit -fsanitize=address. C'est vraiment une dinguerie. On pourrait même voir une amélioration de la fonction auto_free qui prend en paramètre une chaîne de caractères du nom de notre structure pour faire un switch.

Get time​

Fonction plus chill où l'on calcule juste le temps d'exécution de notre fonction. Très utile pour faire du benchmark.

#define MEASURE_TIME(block) {                                \
    clock_t start_time = clock();                            \
    block                                                    \
    clock_t end_time = clock();                              \
    double elapsed = ((double)(end_time - start_time)) / CLOCKS_PER_SEC * 1000.0; \
    printf("Execution time: %.3f ms\n", elapsed);            \
}

Define Error​

Petite X-macro qui prend une macro en argument et qui l'expand.

#define ERROR_LIST(X)          \
    X(ERROR_FILE_NOT_FOUND, "File not found")    \
    X(ERROR_INVALID_INPUT, "Invalid input")      \
    X(ERROR_OUT_OF_MEMORY, "Out of memory")      \
    X(ERROR_UNKNOWN, "Unknown error")

#define DEFINE_ERROR_ENUM(code, message) code,
enum ErrorCode {
    ERROR_LIST(DEFINE_ERROR_ENUM)
};

#define DEFINE_ERROR_STRING(code, message) case code: return message;
const char* get_error_message(enum ErrorCode error_code) {
    switch (error_code) {
        ERROR_LIST(DEFINE_ERROR_STRING)
        default: return "Unrecognized error";
    }
}

/* ... */
enum ErrorCode error = ERROR_OUT_OF_MEMORY;
printf("Error: %s\n", get_error_message(error));

Génération de tests automatisés​

Ici, on génère carrément des fonctions entières avec une macro, parce que le C n'a aucune limite. Moi aussi 👀

#define GENERATE_TEST_FUNC(func, test_value, wanted_value) \
    void test_##func(void) { \
        printf("Test de " #func " avec valeur %d : ", test_value); \
        if (func(test_value)) { \
            printf("Succès\n"); \
        } else { \
            printf("Échec\n"); \
        } \
    }

/* ... */
GENERATE_TEST_FUNC(fibo, 10, 55);

test_fibo();

RTFM​

Il est maintenant l'heure de conclure. Nous avons vu plein de choses très cool. Et si jamais vous êtes tentés, libre à vous de découvrir les macros par vous-même. Donc, conclusion : RTFM.

PS : Pour ce qui est du titre, les macros ne sont pas récursives, elles ne s'expandent qu'avec une profondeur de 1.

Dans cet article, nous explorerons les bonnes pratiques pour la création et l'utilisation de Makefiles dans des projets C quelque soit leurs complexités.

Make, ca sert a quoi ?​

Make est un programme qui a pour but de générer des fichier. Il permet de générer des pdfs, des exécutables et bien plus.

Dans les années 1970, la compilation des programmes devient de plus en plus longue et complexe, nécessitant de nombreuses étapes interdépendantes. La plupart des systèmes alors utilisés reposent sur des script shell, nécessitant de répéter toutes les étapes lors de la moindre correction. C'est dans ce contexte que Make fut développé par le docteur Stuart Feldman en 1977. En gérant les dépendances entre fichiers sources et fichiers compilés, Make permet de ne compiler que ce qui est nécessaire à la suite de la modification d'un fichier source.

Il existe un makefile par défaut, qui définit un grand nombre de règles afin de générer la plupart des fichiers avec lesquels, vous serez amené a travailler.

Pour voir ce makefile, par défaut : make -p

Hello World​

Pour débuter, nous allons prendre un cas très simple celui d'un fichier source unique, dans le même dossier que notre makefile.

.
└── main.c 

Dans ce cas, il existe 2 facons de faire.

$ make main # Je souligne l'absence du .c

Dans cette commande, nous demandons a make de créer le fichier main. Mais comment sait-il qu'il doit utiliser le fichier main.c pour faire notre binaire ? Cela est défini dans les règles par défaut.

Nous pouvons aussi creer un fichier Makefile

# Makefile
my_compilation_rule: 
    gcc main.c

Une fois, le fichier crée, il suffit d'exécuter la commande make (qui, par défaut, exécute la première règle du fichier). Nous pouvons aussi mettre en argument le nom de la règle que nous voulons exécuter make my_compilation_rule.

Plus on est de fou, plus on rit​

Notre projet grossit, nous avons maintenant un deuxième fichier source.

.
├── foo.c
├── foo.h
└── main.c 

Dans l'objectif de faire un makefile propre, nous allons déclarer une variable OBJ qui contiendra nos différents fichiers. On en profite pour déclarer un variable CC pour notre compilateur.

# makefile
CC = gcc
OBJ = main.o foo.o


# Cette variable sera utilisée dans la règle implicite qui compile les .o  
CFLAGS = # My C Flags for the compiler
LDFLAGS = # My linker flags
TARGET = a.out

all: $(OBJ)
	$(CC) $(OBJ) -o $(TARGET) $(LDFLAGS)

Cette fois-ci, nous avons ajouter des dépendances à notre règle all. Maintenant, make sait qu'il faut d'abord faire les fichiers .o avant de pouvoir faire le linkage de tous les fichiers en un binaire.

# makefile
SRC = $(wildcard *.c) # main.c foo.c
OBJ = $(SRC:.c=.o) # main.o foo.o

Dans ce makefile, nous avons choisi de ne pas récupérer, à la main, les différents fichiers source. Nous récupérons automatiquement les fichiers source via la fonction wildcard. Cette fonction agit comme le globbing d'un shell. Dans cette example, elle récupère tous les fichiers terminant par .c.

Nous les convertissons en .o via cette syntax $(NAME:old=new) qui n'est rien de moins qu'un replace. La suite de notre makefile reste néanmoins la même chose.

Clean​

Comme vous avez pu le remarquer, un makefile peut facilement générer un grand nombre de fichiers. C'est pour cela que nous allons créer une nouvelle règle dans notre makefile qui a pour but de supprimer tous les fichiers issus de la compilation.

# ...

clean: 
    $(RM) $(OBJ)
    $(RM) $(TARGET)

Pour les petits curieux qui se demandent ce que signifie la variable RM. C'est un simple alias avec la commande rm -f. Il faut savoir que cette variable peut très bien override. On peut très bien voir RM = echo ou bien RM = mv to/path/ (à la place du remove), cela peut être très utile dans certains projets.

Phony​

Nous l'avons dit au début de cet article, mais make est un utilitaire qui permet de générer des fichiers. Mais que se passe-t-il, si l'on appelle la règle clean et qui existe un fichier clean dans notre dossier.

make: 'clean' is up to date.

Pour éviter ce genre de problème, il faut spécifier dans notre makefile que notre règle n'a pas pour but de générer un fichier. Pour cela, nous utilisons le mot clé phony.

Il suffit d'écrire.

.PHONY: my_rule1 my_rule12 # ... 

On range le repo​

Maintenant, que nous avons réussi à faire un makefile propre, nous allons pouvoir faire évoluer notre projet en mettant nos fichiers dans un dossier src.

.
├── Makefile
└── src/
    ├── foo.c
    ├── foo.h
    └── main.c

Pour cela, il nous suffit de rechercher la liste de nos .c dans le dossier src/ puis de les transformer en .o. On peut modifier le code que nous avons fait ci-dessus.

SRCDIR = src
SRC = $(wildcard $(SRCDIR)/*.c)
OBJ = $(SRC:$(SRCDIR)/%.c=$(SRCDIR)/%.o)
# qui est équivalent à
# OBJ = src/main.o \
#       src/main.o

Where GDB ?​

Il peut être utile d'avoir un règle debug, afin de ne pas avoir à mettre un -g dans nos CFLAGS par défaut.

Pour cela, il suffit de :

debug: CFLAGS += -g
debug: all

On remarque que la règle debug n'a pas de corps. Elle se contente d'ajouter un flag et d'appeler notre règle all.

Tester, c'est tricher​

Pour cet article, nous allons voir comment faire un Makefile pour une test suite criterion.

.
├── Makefile
├── src/
...
└── tests/
    └── foo_test.c

Pour pouvoir lancer, nos tests, il va falloir que l'on trouve les fichiers source du dossier tests, puis linker tous nos fichiers en excluant le fichier main.o.

TEST_DIR = tests
SRC_TEST = $(wildcard $(TEST_DIR)/*.c)
OBJ_TEST = $(SRC:$(TEST_DIR)/%.c=$(TEST_DIR)/%.o)

# ... 

check: $(filter-out $(SRC_DIR)/main.o, $(OBJ)) $(OBJ_TEST)
$(CC) $^ -o $(TARGET) $(LDFLAGS)

On remarque que le fichier main.o est exclus en utilisant la fonction filter-out. On voit aussi l'appel d'une variable pour le moment inconnu. Il en existe un grand nombre.

• $^ : La liste des dépendances de la règle

• $< : Le nom de la première dépendance

• $@ : Le nom de la règle

On teste les tests​

Si l'on parle de test, nous devons forcément parler de coverage. Pour cela rien de plus simple, nous ajoutons les flags a nos variables puis exécutons GCOVR

coverage: CFLAGS += -fPIC --coverage
coverage: LDFLAGS += -lgcov -lcriterion
coverage: check
gcovr --print-summary

Like a pro​

La création d'un dossier build est la cerise sur le gâteau. Elle permet au développeur de faire rm -rf build/ pour faire un clean.

Pour cela, nous allons devoir modifier notre variable OBJ et nous allons devoir créer un règle pour la compilation des .o. Nous ne pouvons plus utiliser les règles implicite.

BUILD_DIR = build
OBJ = $(SRC:$(SRC_DIR)/%.c=$(BUILD_DIR)/%.o)

# Compilation des fichiers source
$(BUILD_DIR)/%.o: $(SRC_DIR)/%.c | $(BUILD_DIR)
$(CC) $(CFLAGS) -c $< -o $@
    
# Creer le repertoire de build
$(BUILD_DIR):
mkdir -p $(BUILD_DIR)

Alors on remarque que cette fois-ci, nous n'avons pas défini une règle, mais avec une variable. Nous avons même utilisé une sorte de regex pour la définir.

Nous avons aussi dû mettre un prérequis en plus, la règle $(build_dir). Le fait de mettre un | signifie qu'il doit d'abord vérifier qu'il est nécessaire de faire cette règle.

Bonus​

Bibliothèque statique​

Pour créer une bibliothèque statique à partir des fichiers source, vous pouvez ajouter des règles au Makefile :

LIB_TARGET = libmylib.a
LIB_OBJS = $(filter-out $(BUILD_DIR)/main.o, $(OBJS))

$(LIB_TARGET): $(LIB_OBJS)
ar rcs $@ $^

Une fois, la librairie crée, vous pourrez simplement la link avec votre binaire.

Makefile récursif​

Si votre projet comporte des sous-modules, vous pouvez utiliser un Makefile récursif. Imaginons un projet avec la structure suivante.

.
├── Makefile
└── src/
    ├── features1/
        ...
        └── Makefile
    ├── features2/
        ...
        └── Makefile
    ├── features3/
        ...
        └── Makefile
    ├── features4/
        ...
        └── Makefile
    ├── main.c
    └── Makefile

Pour cela, il y a deux approches possibles. La première serait de faire un seul makefile à la racine de notre projet et faire un find de nos fichiers .c. Nous verrons comment faire par la suite.

La deuxième, c'est de faire une structure récursif via le Makefile suivant.

# src/makefile 
SUBDIRS = $(wildcard */.)

.PHONY: subdirs $(SUBDIRS)

subdirs: $(SUBDIRS)

$(SUBDIRS):
    $(MAKE) -C $@

Avec ce fichier, nous allons pouvoir mettre un makefile dans chaque dossier features et lui et lui seul gérera la compilation de la features. Ils seront appelés par le src/Makefile via la règles subdirs.

# Makefile

export CFLAGS = -Wall -Werror -pedantic

# ...

N'oubliez pas d'export vos variables dans votre Makefile afin qu´elle s'applique sur les Makefiles suivants.

Ce genre d'architecture nécessite, la plupart du temps, de la combiner avec la création de librairie statique.

Répertoires infinis​

Nous avons vu comment utiliser la fonction wildcard mais comment faire pour recuperer l'intégralité de nos fichiers sources ?

├── Makefile
└── src/
    └── foo/
        └── bar/
            ...
                └── foobar/
                    └── barfoo/
                        └── here.c

La prise en charge des répertoires "infinis" peut se faire via des règles génériques ou bien par l'intermédiaire d'un sub-shell.

Par exemple :

# Attention, il faut que votre systeme possede la command find

SRC = $(shell find $(SRC_DIR) -name "*.c")

ou bien

# Je laisse les plus aventureux d'entre vous dechiffrer ce code

rwildcard = $(foreach d, $(wildcard $(1:=/*)), $(call rwildcard,$d,$2) $(filter $(subst *,%,$2),$d))
SRC = $(rwildcard src,*.c)

ou encore

SRC = $(wildcard src/*.c) \
      $(wildcard src/*/*.c) \
      # ... # 
      $(wildcard src/*/*/*/*/*/*/*/*/*/*/.c)
# S'il vous plait, ne faites pas ca 

$ make conclusion​

En conclusion, l'utilisation judicieuse des Makefiles est cruciale pour la gestion efficace de projets. Il permet d'économiser énormément de temps lors du processus de développement. Ce n'est pas pour rien que la quasi-intégralité de l'industrie utilise cet outil.

Cette article n'étant bien entendu, pas exhaustif, je vous invite à vous renseigner par vous meme afin de découvrir les autres fonctionnalités de cet outil.