Работает ли glib c на платформах с открытым железом или ОС RTOS? - PullRequest
Новая
       91

Работает ли glib c на платформах с открытым железом или ОС RTOS?

3 голосов
/ 10 апреля 2020

Эксперты по встраиванию, возможно ли это без значительных изменений?

Я создаю прошивку с ядром Linux и минимальной ОСРВ, которая запускается при выходе из спящего режима. Один и тот же набор инструментов, aarch64- linux -gnu, используется как для Linux, так и для кода RTOS. Причина, по которой ему не нужен отдельный набор инструментов для ОСРВ, состоящий из чистого металла, заключается в том, что у поставщика есть своя урезанная C среда выполнения, которую он использует вместо glib c.

Но это плохо сделано C во время выполнения отсутствует множество функций, поэтому мы хотим использовать более полнофункциональную. Мы могли бы использовать newlib, но для этого потребовался бы второй набор инструментов, которого нужно избегать.

Но я не могу найти ни одного проекта с голым металлом или ОСРВ, использующего glib c. В настоящее время он может собираться с помощью glib c, но очень скоро вылетает, почти наверняка, потому что мы не вызвали код инициализации glib c: 

_start
   __libc_start_main  
     __libc_csu_init   (call C++ constructors for global variables)
     main

https://github.molgen.mpg.de/git-mirror/glibc/blob/master/sysdeps/aarch64/start.S https://github.molgen.mpg.de/git-mirror/glibc/blob/master/csu/libc-start.c

Но, глядя на __libc_start_main, все гораздо сложнее, чем newlib. Кажется, это зависит от множества Linux объектов, которые не существуют:

  1. dynamici c linking? _dl_aux_init
  2. Pthreads вместо создания системных вызовов для несуществующего ядра

    Обновление: работать для нас означает 

    1. malloc
2. printf,write to serial port, but not to actual files
3. C++ globals initialized correctly
4. no threading

1 Ответ

1 голос
/ 14 апреля 2020

В glib c, malloc зависит от низкоуровневого распределителя, такого как sbrk (или mmap). Вы, вероятно, можете подделать что-то вроде sbrk на голой металлической цели, но вам придется потушить все косвенные malloc зависимости (включая поддержку многопоточности).

glib c * Реализация 1008 * связана с реализацией fopen, которая зависит от dlopen для загрузки кода преобразования набора символов (модули gconv). Это относится даже к статически связанному случаю. В действительности невозможно избежать выхода из динамического компоновщика c без каких-либо далеко идущих изменений.

Инициализация C ++ должна быть довольно простой, чтобы получить правильные результаты, даже для голых железных целей. Я не думаю, что вам нужна какая-либо библиотека lib c для этого, просто немного кода запуска, который соответствует вашим целям. (Для некоторых целей достаточно вызвать функцию magi c _init перед вашим приложением.) Glib c также имеет некоторые сложные средства для этого, но они предназначены для поддержки динамического c связывания и dlopen / dlclose. Для статически связанных двоичных файлов они не нужны.

Высококачественный порт glib c для не Linux. В операционной системе non-GNU определенно много работы. Если целью является голая железная или не POSIX ОСРВ, вам, вероятно, придется начинать со слоя прокладки POSIX. Даже в этом случае результат будет не совсем «glib» c, и вам все равно понадобится отдельная цепочка инструментов.

Может быть лучше go с newlib (или существующей RTOS lib * 1035) *) и получить недостающую функциональность lib c через gnulib и аналогичные проекты.

...