C стандартні бібліотеки з голого металу

Я в основному займаюся розробкою на пристроях, що перенесли Linux, тому стандартна бібліотека С забезпечує багато функціональних можливостей завдяки впровадженню системних викликів, які мають стандартизовану поведінку.

Однак для голого металу немає базової ОС. Чи є стандарт, пов’язаний із тим, як слід реалізувати бібліотеку змінного струму, чи потрібно перевчити особливості реалізації бібліотеки, коли ви переходите на нову плату, яка забезпечує інший BSP?

Так, є стандарт, просто стандартна бібліотека C . Функції бібліотеки не потребують "повноцінної" ОС або будь-якої ОС взагалі, і там є ряд реалізацій, пристосованих до "голого металу", Newlib, можливо, є найбільш відомим.

Взявши для прикладу Newlib, він вимагає, щоб ви написали невелику підмножину основних функцій, головним чином, як обробляються файли та пам'ять у вашій системі. Якщо ви використовуєте загальну цільову платформу, швидше за все, хтось уже зробив цю роботу за вас.

Якщо ви використовуєте linux (напевно, також OSX, а можливо, навіть cygwin / msys?) І вводите man strlen, у ньому повинен бути розділ, який називається щось на зразок CONFORMING TO, який би сказав вам, що реалізація відповідає певному стандарту. Таким чином ви зможете зрозуміти, чи використовуєте ви щось стандартну функцію чи це залежить від конкретної ОС.

Чи є стандарт, пов’язаний із тим, як слід реалізувати бібліотеку змінного струму, чи потрібно перевчити особливості реалізації бібліотеки, коли ви переходите на нову плату, яка забезпечує інший BSP?

По-перше, стандарт C визначає щось, що називається "вільно стоячи" реалізацією, на відміну від "розміщеної" реалізації (саме з цим більшість із нас знайомі, повний спектр функцій C, що підтримується базовою ОС).

"Автономна" реалізація повинна визначати лише підмножину заголовків бібліотеки С, а саме ті, що не потребують підтримки або навіть визначення функцій (вони просто виконують #defines і typedefs):

• <float.h>
• <iso646.h>
• <limits.h>
• <stdalign.h>
• <stdarg.h>
• <stdbool.h>
• <stddef.h>
• <stdint.h>
• <stdnoreturn.h>

Виконуючи наступний крок до розміщеної реалізації, ви виявите, що існує лише дуже мало функцій, яким дійсно потрібно будь-яким чином взаємодіяти з "системою", а решта бібліотеки реалізовується поверх цих "примітивів" ". Реалізуючи PDCLib , я доклав певних зусиль, щоб виділити їх в окремий підкаталог для легкої ідентифікації при перенесенні lib на нову платформу (приклади для порту Linux у дужках):

• getenv()( extern char * * environ)
• system()( fork()/ execve()/ wait())
• malloc()і free()( brk()/ sbrk())
• _Exit()( _exit())
• time() (ще не впроваджено)

А для <stdio.h>(мабуть, найбільш "залученої ОС" із заголовків C99):

• якимось чином відкрити файл ( open())
• якийсь спосіб його закрити ( close())
• якийсь спосіб її видалити ( unlink())
• якимось способом перейменувати його ( link()/ unlink())
• якийсь спосіб написати до нього ( write())
• якийсь спосіб прочитати з нього ( read())
• певний спосіб перестановки всередині нього ( lseek())

Деякі відомості про бібліотеку необов’язкові, оскільки стандарт пропонує лише їх реалізацію стандартним способом, але не вимагає такої реалізації вимоги.

• time()Функція може законно тільки повернутися , (time_t)-1якщо немає механіки хронометражу не доступні.

• Описані обробники сигналів <signal.h>не повинні викликати нічого, крім виклику raise(), немає жодної вимоги, щоб система насправді надсилала щось подібне SIGSEGVдо програми.

• Заголовок C11 <threads.h>, який (з очевидних причин) дуже залежить від ОС, взагалі не повинен надаватися, якщо реалізація визначає __STDC_NO_THREADS__...

Прикладів є більше, але я зараз не маю їх під рукою.

Решта бібліотеки можна реалізувати без сторонньої допомоги. (*)

(*) Caveat: Реалізація PDCLib ще не завершена, тому я, можливо, переглянув річ чи дві. ;-)

Стандарт C фактично визначається окремо від робочого середовища. Не передбачається присутність хост-операційної системи, і ті частини, які залежать від хоста, визначаються як такі.

Тобто C Standard - це вже досить голий метал.

Звичайно, ті мовні частини, які ми так любимо, бібліотеки, часто там, де основна мова підштовхує хостинг конкретних речей. Отже, типові матеріали для компілятора "xxx-lib" знайдені для багатьох інструментів платформи для голих металів.

Приклад мінімальної експлуатації Newlib

Тут я надаю високо автоматизований і задокументований приклад, який показує новоліб в дії в QEMU .

За допомогою newlib ви реалізуєте власні системні виклики для своєї бареметальної платформи.

Наприклад, на наведеному вище прикладі ми маємо приклад програми exit.c:

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

void main(void) {
    exit(0);
}

і в окремому файлі C common.c, ми будемо виконувати exitз ARM semihosting :

void _exit(int status) {
    __asm__ __volatile__ ("mov r0, #0x18; ldr r1, =#0x20026; svc 0x00123456");
}

Інші типові систематичні виклики, які ви будете реалізовувати, це:

• writeдля виведення результатів на хост. Це можна зробити за допомогою:

  • більше напівгості
  • обладнання UART

• brkдля malloc.

  Легко на бареметалі, оскільки нам не потрібно піклуватися про пейджинг!

TODO Цікаво, чи реально досягти випереджувального планування виконання системних дзвінків, не потрапляючи в повноцінний RTOS, такий як Zephyr або FreeRTOS .

Класна річ у Newlib - це те, що він реалізує всі конкретні речі, не для ОС, як string.hдля вас, і дозволяє реалізовувати лише заглушки ОС.

Крім того, вам не доведеться реалізувати всі заглушки, а лише ті, які вам знадобляться. Наприклад, якщо вашій програмі потрібно лише exit, вам не потрібно надавати print.

Дерево джерела Newlib вже має деякі реалізації, включаючи реалізацію напівгостингу ARM під newlib/libc/sys/arm, але здебільшого вам доведеться реалізувати власну. Однак це дає надійну базу для виконання завдання.

Найпростіший спосіб налаштувати Newlib - це створити власний компілятор з crosstool-NG, вам просто потрібно сказати йому, що ви хочете використовувати Newlib як бібліотеку C. Моя установка автоматично обробляє для вас цей сценарій , який використовує конфігурації newlib, наявні в crosstool_ng_config.

Я думаю, що C ++ також буде працювати, але TODO перевірить це.

Використовуючи його бареметалом, ви виявляєте деякі незмінені залежності і вам доводиться впоратися з ними. Усі ці залежності стосуються налаштування внутрішніх даних відповідно до особистості вашої системи. Наприклад, коли я намагався використовувати sprintf (), який використовує malloc () всередині. Malloc має символ функції "t_sbrk" як гачок у коді, який повинен бути реалізований користувачем для забезпечення апаратних обмежень. Тут я можу реалізувати його або зробити власний malloc (), якщо я вважаю, що міг би зробити кращий варіант для вбудованого обладнання, головним чином для інших цілей використання, а не тільки sprintf.