Отличие кросскомпилятора bare metal и for linux на ARM.

Как правило производитель железки, говорю на примере TI и FreeScale, предоставляют toolchain, например для iMX53 предоставляется arm-fsl-linux-gnueabi-gcc, которым собирается всё. И во избежание проблем, в том числе и при общении с технической поддержкой, рекомендуется использовать его.

На сколько я понял два вида тулчейнов отличаются С библиотекой. Под линукс это glibc, под железо - newlib или!!! вообще без C библиотеки.И как сделать универсальным тулчейн? как он определяет под что собирать?

Это наверное я тебя дезинформировал в предыдущем топике, у тебя тулчейн с gnueabi, под bare-metal суффикс -eabi, например, arm-none-eabi-gcc. Проблему сврю, кстати, решил?

Ага...-eabi значит для bare-metal....а на сайте linaro написано - «linux-gnu* for Linux»...то есть такой префикс под Linux.... у меня и то и то получается? у меня уже каша в голове...

Проблему не решил) пока задвинул её в угол за не срочностью и отсутствием решений...

-none- или -unknown- сразу после архитектуры - это вендор железяки, но он может просто опускаться.

Далее идет ОС, для которой предназначен компилятор, в твоем случае -linux-, хотя это значение может опускаться или замещаться на -none-. Насколько мне известно, -linux- в названии кросс-компилятора означает то, что тулчейн всего-лишь поставляется с kernel-headers и линуксовыми библиотеками.

Далее идёт ABI определитель: -gnueabi- означает, что тулчейн использует GNU EABI, и соответственно, glibc/eglibc. Для arm-тулчейнов могут быть ещё такие значения:
-gnueabihf- - тоже самое, но используется GNU EABI с Hard Float;
-eabi- - юзается дефолтный ARM EABI, тулчейны с такими компиляторами - это bare-metal;
-uclibcgnueabi- или -uclibc- - означает, что компилятор будет генерировать код в GNU EABI, но вместо glibc, будет юзаться uClibc;
-newlib- обычно пишется не в ABI, а в ОС, такие тулчейны тоже, как правило, bare-metal;
Если тулчейн не для arm-архитектуры, то EABI/ABI, обычно, опускается. И пишется просто -uclibc-, -gnu- или вообще -elf-.
Примеры:

mips-malta-linux-gnu
m68k-unknown-elf
powerpc-unknown-linux-uclibc

Короче, не парься. Именование tuple нигде нормально не стандартизировано, поэтому лучше всего запомнить такие аксиомы:

1. Если в названии тулчейна есть -elf-, -eabi- или -newlib- то это тулчейн для bare-metal;
2. Если в названии тулчейна есть -uclibcgnueabi- или -uclibc- - то это тулчейн с linux-headers и uClibc.
3. Если в названии тулчейна встречается -gnu- или -gnueabi-, то это тулчейн с linux-headers и glibc/eglibc

Примеры тулчейнов можешь посмотреть тут: http://crosstool-ng.org/

Касательно твоих вопросов:

У меня есть тулчейн - arm-none-linux-gnueabi. Что значит -none-?

Это значит то, что твой тулчейн не собирался компанией-вендором. А если и собирался, то они не проставили значение при сборке.

Этим компилятором я собирал ядро и загрузчик которые относятся к программам for bare metal. Этим же компилятором собиралось Qt и кутишные приложения - и все чудно работает. В чем подвох?

Подвоха никакого нету. Ядро (Linux?) не относится к bare-metal, а вот загрузчик - относится. Никто не запрещает собрать bare-metal элементы linux-овым тулчейном. Обычно эти элементы самодостаточны и им не нужен никакой glibc, как и ядру. Поэтому всё должно работать. Проблемы возникнут, если ты будешь собирать bare-metal компилятором какой-нибудь Qt.

Этот компилятор к какому относится- bare-metal или linux?

Linux.

где взять информацию по этому вопросу?

Выше я тебе немного расписал, подробнее можно найти в интернете.

Совсем просто:
-gnueabi- - тулчейн использует GNU EABI, и он под Linux.
-eabi- - тулчейн использует ARM EABI, и он под bare-metal.

у меня и то и то получается?

Нет у тебя GNU EABI Linux тулчейн.

И как сделать универсальным тулчейн? как он определяет под что собирать?

Короче, смотри:

• Если тебе нужен на твоей железке Linux, Qt, и прочая прикладная требуха - юзай тот тулчейн, который у тебя сейчас. Ты сделал правильный выбор.
• Если тебе нафиг не нужен Linux, и ты обходишься загрузчиком + программой, которую этот загрузчик запускает без OS - тебе нужен bare-metal тулчейн с newlib или вообще без нее. Linux тулчейн для тебя избыточен.

Универсальным тулчейном будет для тебя тулчейн Linux GNU EABI.

Вот спасибо! Стало яснее...возможно я это переварю и появятся еще вопросы)

Никто не запрещает собрать bare-metal элементы linux-овым тулчейном

Зачем тогда вообще нужен bare-metal тулчейны? Собирать все одними и теми же и не мучаться.

Ядро (Linux?) не относится к bare-metal

Я думал не относится все что работает под управлением ОС. Возможно это было ошибочно.

Все.... увидел последнее сообщение)

Вопрос в догонку. Почему в папке тулчейна есть директория /bin в которой находятся бинарники типа : arm-linux-gnueabihf-gcc ..... и есть директория /arm-linux-gnueabihf/bin в которой есть бинарник gcc? Зачем так?

Насколько мне известно, -linux- в названии кросс-компилятора означает то, что тулчейн всего-лишь поставляется с kernel-headers и линуксовыми библиотеками.

Эмммм.....к какому ядру headersы? под какое-то конкретное ядро?

Зачем тогда вообще нужен bare-metal тулчейны? Собирать все одними и теми же и не мучаться.

Как ты уже понял, не каждому Ъ-эмбеддеру нужен на плате Linux, и соответственно, ему нафиг не нужен монструозный glibc. За примерами ходить далеко не нужно - тот же Enterprise, который может быть враждебным по отношению к open-source. Ещё тебе пример - софт для мобилок (для старых нокий, к примеру), компилируется именно arm-eabi тулчейнами, без всяких там linux и уж тем более gnueabi. Там собственный мир со своими загрузчиками, ядрами, собственной реализацией libc и libstdc++ и. др.

Вопрос в догонку. Почему в папке тулчейна есть директория /bin в которой находятся бинарники типа : arm-linux-gnueabihf-gcc ..... и есть директория /arm-linux-gnueabihf/bin в которой есть бинарник gcc? Зачем так?

Для совместимости с кросс-компиляцией видимо сделано, если честно, не разбирался. Буду рад, если мне это тоже объяснят. Но точно тебе скажу, что твой gcc из /arm-linux-gnueabihf/bin и arm-linux-gnueabihf-gcc это полностью одинаковые файлы. Можешь сам проверить по выхлопу ./gcc -v и arm-linux-gnueabihf-gcc -v. У них даже хеш будет одинаковый. Пруф:

md5sum gcc
9c2dcd88c114c755107b47dac110231c  gcc

md5sum ../../bin/arm-qemu-linux-gnueabi-gcc 
9c2dcd88c114c755107b47dac110231c  ../../bin/arm-qemu-linux-gnueabi-gcc

Возможно, при компиляции тулчейна и binutils все они складываются в /arm-linux-gnueabihf/bin, а потом к ним добавляется префикс и они выносятся в ../../bin/

Эмммм.....к какому ядру headersы? под какое-то конкретное ядро?

Да, при создании arm-vendor-linux-gnueabi тулчейна, конкретное ядро определяется: [скриншот].
Версия kernel-headers в тулчейне важна, т.к. она определяет минимальную версию ядра, на котором запустится твоя программа. Поясню:
Допустим у тебя в тулчейне kernel-headers от ядра версии 3.10.2, а это значит, что твоя программа запустится на любых ядрах версии 3.10.2 и выше, но если ты решишь поставить себе в железку ядро 2.6.24, то на нем твоя программа не запустится.
Короче, знай простое правило: не стоит ставить ядро в железяку ниже той версии, что в твоем тулчейне.
Если поставишь, то придется пересобирать тулчейн с linux-headers с корректной версией.

Узнать версию ядра в тулчейне можно так:

exl@exl-Lenovo-G560e:~/SandBox > echo 'main(){ printf("LOL"); }' > main.c
exl@exl-Lenovo-G560e:~/SandBox > arm-qemu-linux-gnueabi-gcc main.c
exl@exl-Lenovo-G560e:~/SandBox > file a.out 
a.out: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.10.2, not stripped
exl@exl-Lenovo-G560e:~/SandBox > arm_v6_vfp_le-gcc main.c
exl@exl-Lenovo-G560e:~/SandBox > file a.out 
a.out: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.4.17, not stripped

Как видишь, у меня это 3.10.2 и 2.4.17 для разных тулчейнов.

Вот наглядный пример:

> cat main.c 
main(){ printf("LOL\n"); return 0; }

> arm_v6_vfp_le-gcc -static  main.c
> file a.out 
a.out: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, for GNU/Linux 2.4.17, not stripped
> qemu-arm a.out 
LOL

> arm-qemu-linux-gnueabi-gcc -static main.c
> file a.out 
a.out: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, for GNU/Linux 3.10.2, not stripped
> qemu-arm a.out 
FATAL: kernel too old
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault

QEMU использует при эмуляции версию ядра 2.6.X.

Универсальным тулчейном будет для тебя тулчейн Linux GNU EABI.

Спасибо, раньше я это интуитивно понимал, а сейчас подтвердил чтением топика :)

Мне тоже стало понятно)