Отлично, статически слинкованная gnu libc реализует вызов open.
Который syscall с небольшой библиотечной обвязкой. Который исполняется ядром.
Кому управление «статически слинкованная» libc передавать будет?
System calls are generally not invoked directly, but rather via wrapper functions in glibc (or perhaps some other library). For details of direct invocation of a system call, see intro(2). Often, but not always, the name of the wrapper function is the same as the name of the system call that it invokes. For example, glibc contains a function truncate() which invokes the underlying «truncate» system call.
# Linker flags.
# -Wl,...: tell GCC to pass this to linker.
# -Map: create map file
# --cref: add cross reference to map file
LDFLAGS+=-nostartfiles -nostdlib -Wl,-Map=$(BOOT_NAME).map,--cref
LDFLAGS+=-T $(BOOTSTRAP_PATH)/elf32-littlearm.lds -Ttext $(LINK_ADDR)
— Лично я здесь вижу -nostartfiles -nostdlib. Для вас это поиск в Гугле, для меня — код из рабочего проекта.
Собирается, работает. С этим проектом я работал. Если в какой-то другой версии GCC (у меня для армов уже много лет 4.4) есть некий no-hosted — увы, это вне моего поля деятельности.
Намекая на то, что все другие ищут в гугле, а только вы являетесь светом знаний в данной области, вы выставляете себя не с самой хорошей стороны.
Контроллеров разнообразных у меня лежит полный шкаф и есть пяток поднятых с нуля версий железок.
snprintf если и будет вообще для данного приложения, то только самостоятельно написанный. Объём, соответственно, будет зависеть от глубины детальности написанного. Можно утащить попроще, можно посложнее.
У меня как-то в голове не укладывается использование GNU Libc без ОС вообще. Может, я не такую кашу какую-то ем? libc.so.6 для STM без операционок бывает? со всеми pthread, nss, так что ли?
Ну например, -nodefaultlibs -nostdlib для начала. -nostartfiles для совсему уж чистоты хочется. Бареметальнее не бывает. Если того требует историческая справедливость, могу вам мейкфайлы загрузчиков разбирать, которые, будучи собраны компилятором со словом -linux- в названии, безупречно работают в отсутствие оного.
Про memcpy уже увы, демагогия. Я не сказал, что libc _только_ сопрягает то, что нужно С с тем, что есть у ядра ОС, но тем не менее в этом его (libc) основная задача.
У компилятора есть опции «не линковать никакие библиотеки по умолчанию». с ними bare metal и собирают.
newlib/gnu libc/uclibc — это прослойки между ядром и юзерспейсом, обеспечивающие определённый интерфейс. Если нет ни ядра, ни юзерспейса — откуда им взяться в bare metal? Уж от пухлости библиотеки поддержки С никакой загрузчик не вырастет, ему что надо, у него всё внутри есть
совсем необязательно. -linux- указывает на наличие libc, но никто не мешает этим компилятором для армов компилировать загрузчик bootstrap (без всего) и ядро линукса (которое тоже с libc не линкуется, как понимаете).
а вот пресловутые стандарты MISRA запрещают использовать нетривиальные макросы. Компилятору и статическим тулзам труднее будет опознать, где же вы там накосячили. И даже разыменование указателей запрещают в макросы прятать.
Юзаю --sysroot для обычного gcc в Linux для разработки под собственный ARM-девайс.
Тонкость возникает, когда нужен pkg-config. --sysroot переопределяет только /usr/include, а не /usr/include/dbus-1.0, к примеру, который записан в dbus.pc
Ему для того, чтобы он прибавлял к записям из базы этот sysroot, нужно дообъявить к PKG_CONFIG_PATH (обычно $sysroot/usr/lib/pkgconfig) ещё PKG_CONFIG_SYSROOT_DIR (== $sysroot). Получаются здоровенные -I и -L, но работает.
Большое спасибо, честно говоря. Среди себя поднимал вопрос давным давно, сравнивая отлаживаемость Java с голыми С. И к тому же backtrace приходил, но сильно далеко не убежал.
«Иудейский народный фронт? ИУДЕЙСКИЙ НАРОДНЫЙ ФРОНТ?! Народный фронт Иудеи! Иудейский народный фронт… вон он сидит, этот фронт: „Раскольник!!!“ (с) Житие Брайана.
Который syscall с небольшой библиотечной обвязкой. Который исполняется ядром.
Кому управление «статически слинкованная» libc передавать будет?
System calls are generally not invoked directly, but rather via wrapper functions in glibc (or perhaps some other library). For details of direct invocation of a system call, see intro(2). Often, but not always, the name of the wrapper function is the same as the name of the system call that it invokes. For example, glibc contains a function truncate() which invokes the underlying «truncate» system call.
Загрузчик at91bootstrap:
CCFLAGS=-g -mcpu=arm926ej-s -O2 -Wall -D$(TARGET) -I$(INCL)
ASFLAGS=-g -mcpu=arm926ej-s -c -O2 -Wall -D$(TARGET) -I$(INCL) -DTOP_OF_MEM=$(TOP_OF_MEMORY)
# Linker flags.
# -Wl,...: tell GCC to pass this to linker.
# -Map: create map file
# --cref: add cross reference to map file
LDFLAGS+=-nostartfiles -nostdlib -Wl,-Map=$(BOOT_NAME).map,--cref
LDFLAGS+=-T $(BOOTSTRAP_PATH)/elf32-littlearm.lds -Ttext $(LINK_ADDR)
— Лично я здесь вижу -nostartfiles -nostdlib. Для вас это поиск в Гугле, для меня — код из рабочего проекта.
Собирается, работает. С этим проектом я работал. Если в какой-то другой версии GCC (у меня для армов уже много лет 4.4) есть некий no-hosted — увы, это вне моего поля деятельности.
Намекая на то, что все другие ищут в гугле, а только вы являетесь светом знаний в данной области, вы выставляете себя не с самой хорошей стороны.
Контроллеров разнообразных у меня лежит полный шкаф и есть пяток поднятых с нуля версий железок.
snprintf если и будет вообще для данного приложения, то только самостоятельно написанный. Объём, соответственно, будет зависеть от глубины детальности написанного. Можно утащить попроще, можно посложнее.
У меня как-то в голове не укладывается использование GNU Libc без ОС вообще. Может, я не такую кашу какую-то ем? libc.so.6 для STM без операционок бывает? со всеми pthread, nss, так что ли?
Про memcpy уже увы, демагогия. Я не сказал, что libc _только_ сопрягает то, что нужно С с тем, что есть у ядра ОС, но тем не менее в этом его (libc) основная задача.
newlib/gnu libc/uclibc — это прослойки между ядром и юзерспейсом, обеспечивающие определённый интерфейс. Если нет ни ядра, ни юзерспейса — откуда им взяться в bare metal? Уж от пухлости библиотеки поддержки С никакой загрузчик не вырастет, ему что надо, у него всё внутри есть
Аргументируют возможностями статической проверки кода компилятором и прочими lint'ами.
До сих пор думаю, как выделять несколько ресурсов и корректно их освобождать в ошибочных и не очень ситуациях без goto.
Тонкость возникает, когда нужен pkg-config. --sysroot переопределяет только /usr/include, а не /usr/include/dbus-1.0, к примеру, который записан в dbus.pc
Ему для того, чтобы он прибавлял к записям из базы этот sysroot, нужно дообъявить к PKG_CONFIG_PATH (обычно $sysroot/usr/lib/pkgconfig) ещё PKG_CONFIG_SYSROOT_DIR (== $sysroot). Получаются здоровенные -I и -L, но работает.
Когда-то долго выяснял и даже «лечил» симлинками.
Обучать надо сразу JavaEE, с первого курса начать с километровых XMLей. И maven, конечно. Это востребованно, это модно!
}
Большое спасибо, честно говоря. Среди себя поднимал вопрос давным давно, сравнивая отлаживаемость Java с голыми С. И к тому же backtrace приходил, но сильно далеко не убежал.
А ваш код прямо сейчас скопипастил, спасибо :-)
Judean Liberation Front.
«Иудейский народный фронт? ИУДЕЙСКИЙ НАРОДНЫЙ ФРОНТ?! Народный фронт Иудеи! Иудейский народный фронт… вон он сидит, этот фронт: „Раскольник!!!“ (с) Житие Брайана.
Пишите код хорошо, и у вас будет хороший код.
Как-то так.