What is arm none linux gnueabi gcc

What is the difference between arm-linux-gcc and arm-none-linux-gnueabi

Toolchains have a loose name convention like arch[-vendor][-os]-abi .

• arch is for architecture: arm, mips, x86, i686.
• vendor is tool chain supplier: apple,
• os is for operating system: linux, none (bare metal)
• abi is for application binary interface convention: eabi, gnueabi, gnueabihf

For your question, arm-none-linux-gnueabi and arm-linux-gnueabi is same thing. arm-linux-gcc is actually binary for gcc which produces objects for ARM architecture to be run on Linux with default configuration (abi) provided by toolchain.

Admin

Comments

What is the difference between arm-linux-gcc and arm-none-linux-gnueabi and arm-linux-gnueabi toolchains? Do they compile differently?

This might be true, but really, there’s not enough information to be sure. You need to know about the provenance of the toolchain. Non-«gnueabi» toolchains are probably quite rare, however.

It’s worth pointing out that tool-chains are configured with default header and library search paths. When cross-compiling, these should be pointing at the target image not the development machine’s own headers and libraries. Thus you can easily end up with a compiler which reports its specification as arm-none-linux-gnueabi that actually compile with slightly different results. You can check this with gcc -print-sysroot

@auselen: Yes, arm-linux seems ambiguous to me. I’ve not checked, and it might be that in current gcc that’s a synonym, but I’ll bet it’s meant something different in the past. Besides, the triplet only specifies the default config, and the toolchain could have been built with other settings enabled; in that case, I would choose the generic triplet rather than have it lie.

@ams if I understand you correctly, you say arm-linux-gcc executes default settings as toolchain have been built. yes you are definitively right.

@Marko thanks for the tip. Toolchains are quite complicated as you point. I just tried to scratch the surface.

Источник

Русские Блоги

Разница между arm-linux-gcc, arm-none-eabi-gcc, arm-eabi-gcc, arm-none-linux-gnueabi-gcc

arm-none-eabi-gcc

==（ARM architecture，no vendor，not target an operating system，complies with the ARM EABI）==

Arm официально используется для компиляции голых металлических систем на базе ARM (включая загрузку и ядро ​​ARM Linux, == не применяется для компиляции приложений Linux ==), обычно подходит для основных чипов ARM7, Cortex-M и Cortex-R, поэтому они не поддерживается Функции, тесно связанные с операционной системой, такие как fork (2), используют newlib, библиотеку C, предназначенную для встраиваемых систем.
ссылка для скачивания

arm-none-linux-gnueabi-gcc

==(ARM architecture, no vendor, creates binaries that run on the Linux operating system, and uses the GNU EABI)==

В основном используется для систем Linux, основанных на архитектуре ARM, == может использоваться для компиляции u-boot, ядра Linux, приложений Linux и т. Д. Архитектуры ARM ==. arm-none-linux-gnueabi основан на GCC, использует библиотеку Glibc и является компилятором, оптимизированным Codesourcery. Вычисления с плавающей запятой в инструментах кросс-компиляции arm-none-linux-gnueabi-xxx превосходны. Обычно их используют ядра ARM9, ARM11, Cortex-A и операционная система Linux.
ссылка для скачивания

arm-eabi-gcc

armcc

Инструмент компиляции, запущенный ARM, имеет аналогичные функции с arm-none-eabi. Он может компилировать программы с нуля (u-boot, kernel), но не может компилировать приложения Linux. Armcc обычно работает с ARM. Все компиляторы в Keil MDK, ADS, RVDS и DS-5 являются armcc, поэтому все компиляторы armcc являются платными).

arm-none-uclinuxeabi-gcc и arm-none-symbianelf-gcc

arm-none-uclinuxeabi используется для uCLinux с использованием Glibc.
arm-none-symbianelf используется для Symbian.

ABI и EABI

ABI

Двоичный интерфейс приложения (ABI) для архитектуры ARM. В компьютере двоичный интерфейс приложения описывает низкоуровневый интерфейс между приложением (или другими типами) и операционной системой или другими приложениями.

EABI

Встроенный ABI. Двоичный интерфейс встроенного приложения определяет формат файла, тип данных, использование, оптимизацию организации стека и стандартные соглашения о параметрах во встроенном программном обеспечении. Разработчики, использующие собственный язык ассемблера, также могут использовать EABI в качестве интерфейса с совместимым сгенерированным языком ассемблера.

== Основное различие между ними состоит в том, что ABI находится на компьютере, а EABI находится на встроенной платформе (например, ARM, MIPS и т. Д.). ==

arm-linux-gnueabi-gcc и arm-linux-gnueabihf-gcc

Два кросс-компилятора применимы к двум различным архитектурам, armel и armhf. Armel и armhf используют разные стратегии для операций с плавающей запятой (руки с fpu могут поддерживать эти две стратегии операций с плавающей запятой).

Фактически, эти два кросс-компилятора представляют собой просто разные значения по умолчанию для параметра gcc -mfloat-abi. Параметр gcc -mfloat-abi имеет три значения:

soft, softfp, hard (последние два требуют блока с плавающей запятой fpu в arm, soft совместим с двумя последними, но два режима softfp и hard несовместимы друг с другом):

1. soft: не используйте fpu для вычислений с плавающей запятой, даже если есть модуль fpu с плавающей запятой, он не использует его, но использует программный режим.
2. softfp: значение по умолчанию, принятое архитектурой armel (соответствующий компилятор — arm-linux-gnueabi-gcc), вычисляется fpu, но параметры передаются обычными регистрами, так что при прерывании нужно сохранять только обычные регистры, и нагрузка прерывания мала, но для пересчета параметры необходимо преобразовать в числа с плавающей запятой.
3. жесткий: значение по умолчанию, принятое архитектурой armhf (соответствующее arm-linux-gnueabihf-gcc), вычисляется с помощью fpu, и параметры также используются для передачи с плавающей запятой в fpu, что устраняет необходимость преобразования и имеет лучшую производительность , но нагрузка прерывания высока.

Сохраните содержимое файла C, используемого в следующем тесте, как mfloat.c:

1. Используйте arm-linux-gnueabihf-gcc для компиляции, используйте опцию «-v» для получения более подробной информации:

# arm-linux-gnueabihf-gcc -v mfloat.c COLLECT_GCC_OPTIONS=’-v’ ‘-march=armv7-a’ ‘-mfloat-abi=hard’ ‘-mfpu=vfpv3-d16′ ‘-mthumb’ -mfloat-abi=hard 

Видно, что используется аппаратный аппаратный режим с плавающей запятой.

# arm-linux-gnueabi-gcc -v mfloat.c COLLECT_GCC_OPTIONS=’-v’ ‘-march=armv7-a’ ‘-mfloat-abi=softfp’ ‘-mfpu=vfpv3-d16′ ‘-mthumb’ -mfloat-abi=softfp 

Видно, что используется режим softfp.

Разница между кросс-компиляцией и локальной компиляцией

[Ошибка загрузки изображения . (image-c32fba-1546832274447)]

установка

Установите arm-linux-gnueabi-gcc или arm-linux-gnueabidf-gcc:

sudo apt-get install gcc-arm-linux-gnueabi sudo apt-get install gcc-arm-linux-gnueabihf 

Установите arm-linux-gnueabi-g ++ или arm-linux-gnueabidf-g ++

sudo apt-get install g++-arm-linux-gnueabi sudo apt-get install g++-arm-linux-gnueabihf 

Удалите arm-linux-gnueabi-gcc или arm-linux-gnueabidf-gcc

sudo apt-get remove gcc-arm-linux-gnueabi sudo apt-get remove gcc-arm-linux-gnueabihf 

Удалите arm-linux-gnueabi-g ++ или arm-linux-gnueabidf-g ++

sudo apt-get remove g++-arm-linux-gnueabi sudo apt-get remove g++-arm-linux-gnueabihf 

Источник

What is the difference between arm-linux-gcc and arm-none-linux-gnueabi

What is the difference between arm-linux-gcc and arm-none-linux-gnueabi and arm-linux-gnueabi toolchains? Do they compile differently?

1 Answer 1

Toolchains have a loose name convention like arch[-vendor][-os]-abi .

• arch is for architecture: arm, mips, x86, i686.
• vendor is tool chain supplier: apple,
• os is for operating system: linux, none (bare metal)
• abi is for application binary interface convention: eabi, gnueabi, gnueabihf

For your question, arm-none-linux-gnueabi and arm-linux-gnueabi is same thing. arm-linux-gcc is actually binary for gcc which produces objects for ARM architecture to be run on Linux with default configuration (abi) provided by toolchain.

This might be true, but really, there’s not enough information to be sure. You need to know about the provenance of the toolchain. Non-«gnueabi» toolchains are probably quite rare, however.

It’s worth pointing out that tool-chains are configured with default header and library search paths. When cross-compiling, these should be pointing at the target image not the development machine’s own headers and libraries. Thus you can easily end up with a compiler which reports its specification as arm-none-linux-gnueabi that actually compile with slightly different results. You can check this with gcc -print-sysroot

@auselen: Yes, arm-linux seems ambiguous to me. I’ve not checked, and it might be that in current gcc that’s a synonym, but I’ll bet it’s meant something different in the past. Besides, the triplet only specifies the default config, and the toolchain could have been built with other settings enabled; in that case, I would choose the generic triplet rather than have it lie.

@ams if I understand you correctly, you say arm-linux-gcc executes default settings as toolchain have been built. yes you are definitively right.

Источник

Difference between arm-none-eabi and arm-linux-gnueabi?

What is the difference between arm-none-eabi and arm-linux-gnueabi? I know the difference in how to use them (one for bare metal software, the other one for software meant to be run on linux). But what is the technical background? I see there is a difference in the ABI which is, as far as I understood, something like an API but on binary level. It ensures interoperability of different applications. But I don’t really understand in which way having or not having an operating system affects my toolchain. The only thing that came to my mind is, that libraries maybe have to be statically linked (do they?) while compiling bare metal software, because there is no os dynamically providing them. The most pages I found related to this toppic just answered how to use the toolchains but not the technical background. I’m a student of mechatronics and new to embedded systems, so my experience in this field is somewhat limited.

Yes it is mostly a library thing, trying to tune for running on linux (libc, etc) vs I think newlib. For bare metal work, either is fine as they can both make assembly from C and make objects from assembly and link with your own linker scripts, etc. And the bare metal i am talking about is one without standard libraries and/or you use this tool to create your own libraries from sources. Basically they both work as generic cross compilers, if you want/need built in library support, then it may matter which one you use.

@dwelch: There is no need to use any library on bare-metal. You just possibly have to provide some functions (mostly memcpy , etc.) gcc might call (e.g. when assignming structs ).

@Olaf I dont use C libraries on bare metal, but some folks do, and of those some use newlib (or whatever is friendly to that build), and of those some want to use arm-none-eabi instead of arm-linux-gnueabi because it does matter to them. So it depends on what the OP is targeting as to whether or not the differences matter.

@dwelch: I strongly doubt arm-linux-gnueabi will work for bare-metal systems. Never tried it, though. For one, iirc, arm-none-* is a freestanding implementation by default, so it does not rely on the C stdlib for hosted systems and gcc does not use its built-in optimisations for certain standard library functions.

@Olaf most if not all of my work and personal bare metal code can use either variant as I dont rely on anything but a compiler that can make asm from C and assembler that can make machine code from asm, and a linker that links only the things I have supplied together. It is very dependent though on the user and their code and build system. More likely to get tripped up with the -linux- one. And yes the gcc lib things can very quickly get system dependent so I control those as well.

Источник