1 of 51

C++ In Early Boot

Elazar Leibovich

Core C++ 2025�19 Oct. 2025 :: Tel-Aviv

2 of 51

3 of 51

C++ in Early Boot

And other bad ideas

4 of 51

Agenda

  1. Prior art
  2. Quick ARM Boot Recap
  3. U-boot C++ journey

5 of 51

Prior Art

​

Keep in mind that U-Boot is a boot loader. If you have fancy things

like C++ code you should use an operating system instead.

​

Best regards,

​

Wolfgang Denk

6 of 51

Private Correspondence

I've had a very quick glance [in this presentation EL]. While I think the the experiment is interesting, I don't think that C++ in a bootloader is a good idea.

​

(anonymous u-boot contributor reviewer)

7 of 51

OSv, includeOS

Not that maintained

Not that early boot

Allows all C++ features possible!

8 of 51

OSv, includeOS

Not that maintained

Not that early boot

Allows all C++ features possible!

Early boot code is actually… assembly…

9 of 51

10 of 51

ARM recap

PSCI (lives after boot, e.g., RAM frequency)

OP-TEE

ELI

Trustzone

SPL

ATF

11 of 51

C is not (just?) a language!

“C is the lingua franca of programming. We must all speak C, and therefore C is not just a programming language anymore – it’s a protocol that every general-purpose programming language needs to speak.”

12 of 51

Our Goal

  • U-boot
  • Prompt
  • Customize

13 of 51

Prerequisites

  • QEMU with arm Support
  • U-Boot
  • Cross compiler gcc-c++-aarch64-linux-gnu (I used gcc 12)

14 of 51

Build

15 of 51

Run

16 of 51

C++

17 of 51

C++

18 of 51

C+

19 of 51

C++

20 of 51

C++

21 of 51

libstdc++?

22 of 51

Existing libstdc++? Arch dependent

23 of 51

libc++?

24 of 51

libc++? GPT has bugs

25 of 51

libc++? 1271 for include <string>

26 of 51

27 of 51

ETL? With std

28 of 51

ETL? No std

29 of 51

ETL? Needs libc anyhow

30 of 51

ETL. Use u-boot libc? No math.h, no sine in early boot

31 of 51

ETL? Let’s use embedded libc!

32 of 51

ETL? Exceptions have personality

33 of 51

ETL? Exceptions have personality

34 of 51

ETL

35 of 51

ETL? DSOs? Where we’re going we don’t need DSOs

36 of 51

ETL? DSOs? Where we’re going we don’t need DSOs

37 of 51

ETL? Static is thread safe!

38 of 51

39 of 51

ETL? Static is thread safe!

40 of 51

ETL? We have not threads!

41 of 51

Hurray!

42 of 51

If result is a global variable?

43 of 51

Who calls the constructor?

44 of 51

Better now!

45 of 51

The cost?

46 of 51

2255 bytes == 2Kb

47 of 51

Almost another 1K

48 of 51

SPL == Secondary Program loader size?

49 of 51

More issues

  • Implicit allocations (e.g., capture lambda assignment)
  • Runtime requirements
  • Debug mode with no optimization matters here
  • Implicit function calls (Stack size in debug mode)
  • Stable ABI (e.g. PSCI lives even after boot)
  • Formal verification
  • Debuggability

50 of 51

More issues

  • Implicit allocations (e.g., capture lambda)
  • Runtime requirements
  • Implicit function calls (Stack size in debug mode)
  • Stable ABI (e.g. PSCI lives even after boot)
  • Debuggability

51 of 51

Summary

  1. In restricted environment C++:
    1. Requires more runtime
    2. Requires C standard library and C++ standard library
  2. Limiting oneself to C types�ease interop
  3. C++ benefits don’t always�outweigh the cost
  4. Simplicity and lack of features �has their merits.